Software in the cloud – from monolith to microservices
Just because your software is running in the cloud doesn’t mean that it’s already cloud native. To unlock the full added value available in the cloud, software needs to be based on a different foundation. The old, monolithic architecture of software needs be transformed into a flexible architecture based on microservices. This not only calls for innovation and technological savvy; organisational change and a well thought-out process will also be indispensable.
The transition explained
Every software application actually consists of a collection of functionalities that work together. Take an online store, for example – the search facility, the recommendation algorithm, the shopping basket and other similar modules come together to form the application itself. Whenever we put all of these functionalities together in the same ‘run-time’, and cause them to operate as a single unit, we speak of a monolithic architecture.
In a cloud-native architecture, you actually detach the different functionalities from each other, allowing them to become microservices that communicate between themselves. These microservices can operate in containers – a software package within a virtual operating system (OS) that is able to operate in almost any environment. What makes this setup “cloud native” is the fact that the applications have been built in a way that allows them to benefit from the scalability, flexibility and resilience that the cloud has to offer.
A cloud-native microservice architecture provides various advantages:
- Easier to scale up or scale down. When using a monolithic architecture, you can only scale up or scale down the architecture as a whole. Microservices, on the other hand, can be fine-tuned and streamlined individually, which means you can free up additional capacity for frequently used functionalities, without driving up the costs of other environments.
- More flexibility. A monolithic architecture is tied to one specific operating system and webserver. Allowing the individual apps to operate in containers, on the other hand, gives you flexibility when making such choices. You can even migrate the apps to a different cloud provider, as a container contains all of the elements needed to enable the app to operate in any environment.
- Easier to manage. Cloud-native applications are easier to manage. That is because you can run them in the cloud and updates to operating systems can take place behind the scenes. Management tools such as Kubernetes and OpenShift also make managing containers considerably more efficient.
The technical challenges posed by microservices
While cloud-native technologies make life that little bit easier, they also pose a certain number of challenges. Cloud technology is developing at an extremely fast pace, and that definitely is something you need to keep track of. For example, if you make a mistake when rolling out a technology such as Kubernetes, it is highly likely that the environment won’t be fully secure, and will form a target for hackers.
Maintaining an overview can also be more difficult. A monolithic application is conveniently structured. What you have is a single environment with fixed costs. In a cloud-native environment, you can upscale the capacity in an unlimited way. You therefore need to set up the right control mechanisms and limits, so that applications continue to perform without incurring costs running into thousands of euros per month as a result of using too much capacity.
Migrating from a monolithic architecture to microservices also poses challenges in terms of monitoring and alerting. After all, the architecture will have been transformed into a complex of small services operating for short or long periods of time. Monitoring these will require new tooling, different expertise, and also a different mentality. Preparing for this and training your staff accordingly is therefore extremely important.
Finally, security is something you need to think about at all times. Are the solutions deployed, such as containers, CI/CD and monitoring, secure and compliant enough to meet your organisation’s needs? After all, a tiny error in the set-up, or a single password finding its way into the public domain, can give rise to a major security breach.
In addition to technical challenges, the transition from a monolithic architecture to microservices is accompanied by a certain number of organisational issues. The team structure and working method will need to be turned upside-down – teams will no longer be working together on a single large release, but will be required to work on small releases for each microservice, and will use a CI/CD release process in their development work. What’s more, teams will also be fully responsible for the functioning of their microservice(s). Referring tasks such as troubleshooting on to a hosting department will also no longer be possible. Without a robust change management process, these changes may therefore cause a degree of friction.
The financial strategy will also need to change. In the cloud, costs aren’t charged for in advance, but are incurred on the basis of usage. It is therefore necessary to be aware of the costs in advance, and be in a position to control them. An incorrect choice, or incorrect setting, can cost thousands of euros, but by actively monitoring this and staying in control, you can block those choices before they are passed on to the production environment.
A carefully considered transition
The switch from a monolithic structure to microservices therefore creates a whole host of challenges. Without a robust process to support this transition, you will be exposing your organisation to unnecessary threats. One of the tried-and-tested processes that can be used while working through this transition is the Strangler Pattern.
This is a transition process based on incremental changes – functionalities are rebuilt into a microservice, item by item. Once the new functionality is ready, the outgoing component within the monolithic architecture is ‘strangled’, and replaced by a link to the new microservice. That way, you can dismantle the monolithic architecture piece by piece, without needing to take the entire application out of service.
That doesn’t mean to say though that when using Strangler Patterns, you won’t encounter any obstacles at all during the transformation to a cloud-native architecture. At such times, it is a reassuring feeling to have an experienced sparring partner that has worked through these types of processes many times before. That will prevent you reinventing the wheel each time, and will help you avoid many of the pitfalls that regularly occur.