Assemble your FlatPacked Composite App in No Time with Microservices

Sometimes the best ideas seem obvious. Why didn’t I think of that, and how did we ever do without it? Microservices could do for software engineering what IKEA did for furniture making. If we can buy ready-made application components then custom apps can be built easier and faster. 

A quick definition: Microservices are ready-made, self-sufficient solutions to manage each specific app component, so we can combine trustworthy components to make an app rather than having to build each part. This in effect creates a composite app of different microservices, communicating with each other through a set of APIs.

While DevOps is making huge strides in release velocity, we are still building each app component from scratch. Instead of buying a flat-packed bed, we are cutting down trees and carving wood to make a frame, making springs for the mattress and so on. DevOps is a tried-and-tested best practice for how IT staff should work together for speed; automation allows them to commit their tasks much quicker than humans can and now microservices might be the final piece in the puzzle of how to release apps at maximum velocity.

Let’s take the example of an eCommerce site: Once you build the pretty front end, you need many robust back-end components to make the site functional: a login/password form, a payment gateway, a shopping cart app, a credentials/session app, search functionality and so on. These don’t need to be pretty; they just need to work. If we can just choose the best ready-made microservices for the job rather than having to develop each of these ourselves, we can either spend more time on the tasks that need our creative thought, or simply launch the site much faster.

Each microservice is managed on its own lightweight platform, rather than all components sitting together on one central platform. This distributed, abstracted system allows us to isolate and troubleshoot when problems arise, and only reset an individual microservice as required rather than the whole app. Each microservice takes just seconds or less to restart, which goes unnoticed by users, while restarting the whole app could take minutes. This is the equivalent of only resetting Microsoft Word if the program freezes when I am writing this blog, rather than having to reset my whole laptop and every app on it.

At present, all these components are controlled by a single middleware platform and are all linked. This means when we want to update your app we need to upload the whole package. Microservices allow the specialization of services so we can just update the innovative parts of the apps that bring use business value, and leave the other more functional bits as they are.

Specialization in this manner allows each microservice to be sourced from external companies that are experts in that field and can build a trusted reputation. Rather than a jack-of-all-trades developer making every component of an app, we can ensure that each component is made and exhaustively tested by developers that specialize in that particular area. We can assign our own team members to work on specific aspects of an app so we can define workloads more precisely.

As with any new technology added to the stack, microservices increase complexity. Their nature means we will take on many new services that need sourcing, implementing and managing. When considering a switch to microservices, we have to weigh up whether they would give more flexibility, or less. This is where automation can help. Dropping all microservices into an orchestration layer can manage the dependencies between them and reduce the need for repetitive manual input. As complexity increases, automation becomes more crucial.

In the future, an automation tool could be used to calculate which microservice to use based on the requirements of the app and the cost of the services that match it, like a brokerage if you will. An automation engine could produce a blueprint of what microservices are needed to produce a certain app based on past experience of what works best.

Any decision on whether to switch to a microservices architecture should be based on agility. If microservices gives you the ability to make changes faster, then it is worth using. With the amount of complex new technologies claiming to increase agility, the simplicity microservices offers is refreshing and could lead to yet another exciting increase in release velocity.