Microservices has been a buzzword for quite a while and has recently picked up steam as cloud services are becoming more readily available and companies can easily access and use cloud resources. It’s important to note that microservices is not an entirely new approach to software engineering, but rather an architectural pattern that gathers “together those things that change for the same reason, and separate those that change for different reasons”, as explained by co-founder of the influential Agile Manifesto, Robert C Martin. When considering microservices, the first question one might ask is why? And to answer that, we need to rewind a bit and look at existing legacy architecture to see where this paradigm fits.
In the good old days, a bare metal stack meant a machine that could run nearly everything (web server, FTP, database, caching – the whole shebang). These services were later designated to separate machines to offload processing, creating a macroservice architecture. When it came to handling load, you had to provision enough headroom (CPU, memory, disk space) to cater for expected throughput. If this throughput was exceeded, machines would crash and systems would go down, often creating a cascading effect on other linked services. Growth was a big challenge – providing more throughput meant months of provisioning hardware, installing into racks and networking. Then the cloud came along and changed all of that. Now we’re able to spin up and adjust macroservices at the flick of a wrist, provided we have the budget to support this flick.
Although we have the macroservices sorted, some services take a bigger hit when load comes into play, and normally at a pretty steep cost. A traditional web stack would be seen as a macroservice – we have lots of users, massive amounts of metadata and probably a few interactive events like registration emails, verification etc. Having a CDN mitigates the majority of traffic, but once we need to start storing data and responding to the user, we start using a lot more processing power.
The problems start rolling in when expectations are set low, and the system is only optimised to reach set goals and expectations. Let’s say, for example, that your company’s marketing department sends out a promotional email and tells the DevOps team that the expected interaction rate is 40 000. So they scale up for the expected interaction rate and trust that all will be well. Then, for some reason, more users interact with this marketing email and the system is flooded with registrations. Consequently, the email provider can’t handle the load and now support is being hammered with requests from users who did not receive their activation codes. The code to send the email is now locking up due to no response from the email provider and users decide to re-register and repeatedly punch F5, shooting the request count through the roof (cue Dead Matter). At this point, auto-scaling kicks in and you’re spinning up web servers, load balancers and databases, all because one process in the entire stack brought the system to its knees.
This is where microservices come into play. By adding a simple queue or seperate service that can mitigate unexpected load, while still providing engaging interaction, we could’ve prevented the scenario outlined above. But that comes at the cost of complexity.
So how do you decide that integrating microservices is a necessity rather than a very costly nice-to-have? The rule of thumb is to look at your budget and work from there. Microservice architecture can accrue significant overhead costs, and using microservices for applications that cannot make sufficient use of their advantages is a waste of precious time and resources. If a client or project manager comes to you with the request to build something using microservices architecture, look carefully at the demand expected and see if it requires that level of complexity. In most cases a standard stack will suffice and, ultimately, it all comes down to the demand.
At Swipe iX, we use microservices not as an answer to all problems, but as a solution when it is needed. If you need some tips or pointers on which architecture would work best for bringing your ideas to life, get in touch! We’re always eager to be part of something extraordinary and make the impossible possible.
Solutions Architect