Moving to a microservices architecture
Alongside containerisation, ‘microservices’ is very much a software development buzzword. But just like with containers, the innovative and far-reaching technology behind the buzzword makes the microservices concept far more than just a passing fad. And if you’re already building containerised applications, moving to a microservices architecture could be the next logical step.
What are microservices?
Before getting into the details, it’s important to nail down a clear definition of microservices. Simply put, microservices are standalone pieces of code designed to do specific jobs, with the ability to work independently or together as required.
Microservices contrast with the more traditional ‘monolithic’ style of service architecture, where an application is built as one big block with a single file system, shared databases and a common language across its various functions.
A microservices-based application still looks like one big continuous system, but behind the scenes, its functions are broken down into individual components for specific tasks. For example, in an ecommerce application these components would each handle a key business capability like product search, recommendations, payment, order tracking or customer reviews.
Microservices manage their own data independently and are ‘language neutral’. Unlike a monolithic system built on a common codebase, microservices are free to use whatever language is most suitable for their task. But while microservices each have their own role and language, they still talk to each other and work together.
JSON-based REST APIs are popular and easy to implement. For high performance data transfer or where you need streaming support, consider GRPC (www.grpc.io). It’s good practice to have live documentation for your API alongside the code using a framework like Swagger or API Blueprint.
Benefits of a microservices architecture
In a monolithic architecture, services are tightly coupled, meaning they’re highly dependent on each other to function properly. Microservices are only loosely coupled, so they’re capable of running as part of a solution or independently. This means that the breakdown of an individual microservice shouldn’t crash the whole application. And because microservices are so lean, they’re easily scalable across multiple servers and virtual machines, so new services can be quickly deployed in the event of failure or increased usage demands.
On the development side, a key advantage of microservices is how they can be tackled in bitesize chunks. Unlike traditional architectures, microservices can be deployed in isolated packages, making regular deployments more practical. Whereas the drama of deploying a monolithic architecture might limit it to a few deployments a week, the modular operation of microservices could enable several deployments a day.
While changes made to a monolithic application can often have a ripple effect through thousands of lines of code, microservices can be worked on in isolation, with the reassurance that changes to one service are unlikely to have a major impact on others. The standalone nature of microservices also simplifies testing, making it easier for problems to be identified and corrected on a per-feature basis. All this means shorter development cycles, faster deployments and more effective responses to customer demands.
Ultimately, microservices can add more complexity than traditional service architectures – but for good reason. They provide a range of benefits including improved scalability, turnaround time and resilience. That said, the complexity of microservices can make them very demanding to implement. It may not always be worth going down the microservices route, particularly for smaller applications.
Microservices and containers: together at last
Containerisation technologies such as Docker and Kubernetes unlock the full potential of microservices by providing platforms and management tools to efficiently implement them. By their very nature, microservices need to be lightweight and able to run anywhere.
The code in a container can function as its own application, with everything it needs to run inside a totally isolated environment that can be easily shifted around. It doesn’t matter what language the application is written in, because all the relevant settings and libraries are included, ensuring consistent behaviour across a wide range of systems.
Replace the idea of a whole application inside a container with a microservice (which itself is effectively a whole application) and it’s obvious that containers offer the ideal microservice environment. While it would technically be possible to build microservices on traditional server hosting alone, the practical reality of creating and maintaining a full microservices architecture demands a container platform like Docker and an orchestration tool like Kubernetes.
Whichever style of service architecture is right for your project, you’ll find the perfect environment on our CloudNX platform. Spin up as many virtual machines as you need to, with full resource scalability and total cost control, plus the reliability of UK data centres and 24/7 support.