Today’s software can be very complex. Noone is going to argue that point. Many SaaS applications are composed of API calls to numerous other applications and services. Previously, the software paradigm was to build large monolithic software applications in whatever language seemed best suited to run the entire platform, “We need it to do X, Java is best for that. If we need it to do Y, then we should use .NET, if we need it to use Z then well, maybe we should use (insert language of the week)” Today we need our SaaS applications to do XYZ and the rest of the alphabet as well. Enter the world of microservices.
I recently witnessed Dorel Vaida giving a presentation to his colleagues on the benefits of microservices and why in so many cases they are both the present and future of SaaS software programming. It was a high level talk meant to get his peers and colleagues thinking about the future of the software they are building while also easing them into the paradigm. He covered concept, orchestration, security, monitoring and scaling, infrastructure, deployment and even talked about some of the new tools that have cropped up recently to help us manage our microservices (Docker, Deis, Flynn, Kubernetes, CoreOS, etc). I would like to breakdown some of the highlights of Dorel’s presentation.
Microservices is a coin popularized by software engineer Martin Fowler.
“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
There are clear benefits in designing software like this, a few of the most prevalent:
Simple and focused on one thing Fault tolerant, isolated from other service failures Language/platform agnostic - pick the right tool for each microservice as opposed to having to select which language has the most upside and least downside Deployed, monitored, scaled (ops) independently
But then there are also the challenges that come along with microservices.
Orchestration Discovery Security
Orchestration with microservices is one of the most challenging aspects, but also one of the reasons why it is so powerful. By breaking our services down into parts, we can call them asynchronously based on events, much like a conductor with an orchestra. Conversely, a monolithic program runs more like a steam engine, running head first and synchronously until it reaches its destination or runs off the tracks. And while this orchestration can be a large challenge when running microservices it also gives us immense amounts of flexibility once we have it running.
Because all of the seperate moving parts we are introducing in a system based on microservices discovery and definition take on much more increased importance. We must know define exactly what processes are responsible for doing what as well as where exactly those processes lay in our overall design. This discovery is vital in the orchestration process.
Security poses a challenges with microservices. Instead of having to secure a single application we are now responsible for having to secure individual microservices. On the flip side of the coin we can also apply varying degrees of security to different parts of our microservices which allows us a good amount of give and take with regards to different pieces.
Now back to the fun stuff. The biggest benefit of utilizing microservices in our software architecture is the long term flexiblity it gives us with regard to scaling.
In my eyes, and maybe my biggest takeaway from Dorel’s presentation was on the advantages of microservices with regards to scaling. Scaling out is one of the most powerful reasons to use microservices to architect your software.
Scenario A - the Monolith
Company A built a piece of software that runs perfectly for 1000 users. But suddenly, they being to grow rapidly and their user base begins expanding. A plethora of performance issues begin cropping up, latency, storage, etc. Now they have to go back into their giant codebase and a) find out what is creating the problem and b) refactor and reprogram the whole machine knowing that with every change they make to one piece, something else may be affected. This not only can create tons of downtime and/or a completely non-functional system but it leaves developers constantly guessing what is going to break next, and often working from a never ending backlog of problems. This is the kind of fat from the cow that can cost large companies millions of dollars and costs many a startup its life.
Scenario B - the Microservice Startup
Company B has the same 1000 users when they start expanding rapidly. They quickly find out that there servers aren’t able to handle all of the database calls effectively when they get many more users than that accessing their database at one time. Luckily, because of the structure of their application they can quickly see what is failing. Because of this, they can scale in pieces, altering only the microservices which are currently in need of love without affecting the rest of the machine.
I got a chance to speak with Dorel about microservices and the shift away from monolithic software architecture. He is currently in the process of switching a few clients from a monolithic architecture style to one that is based more on the use of microservices. And when his consulting requires building new complex solutions for companies microservices is almost always the answer. Like he said, it’s not about if we use them, it’s about how fast we can convert and/or start incorporating them into our applications.