Intro to Cloud Microservices in GxP Environments: Part 1

This is a two-part series on microservices. In the first one, we’ll discuss what a microservice is and its benefits.

Microservices architecture has become an essential aspect of modern software systems, offering numerous advantages over traditional monolithic systems. By enabling development teams to create services that focus on a single business function, microservices allow for greater flexibility and scalability in distributed systems. However, effective strategies must be implemented to ensure microservices blast radius reduction and prevent service failure from starting a chain reaction that can bring down an entire server, which can be achieved using a distributed system instead of a monolithic system. Minimizing the blast radius of system failures ensures that issues in one service don’t cause cascading failures across the entire application. For instance, when a microservice encounters a problem, it is isolated from the rest of the system, containing the blast radius and preventing widespread outages. Additionally, utilizing patterns like the bulkhead pattern, circuit breaker pattern and service registry helps maintain stability, manage the message flow within these systems and reduce the blast radius for minimal impact. This isolation also supports careful consideration of security concerns, allowing each microservice to own its own database and digital footprint, enhancing data integrity and access control. Moreover, asynchronous communication between microservices further improves system resilience, boosts responsiveness and streamlines communication across processes. By streamlining the deployment process and enabling on-demand scaling, microservices not only reduce the microservices blast radius but also simplify the upgrade process, ultimately providing better performance and resilience for complex software ecosystems.

What is a microservice?  

What is a microservice? A simple question, but one without a definitive answer – even Wikipedia struggles: “There is no single definition for microservices”.  

For our purposes, we’re going to take the view that it is a stand-alone piece of business functionality that does one thing and does it well. Let’s look at an example within the IDBS platform – malware scanning.  

Security and data flow is important to us, and when a user uploads a file to the application, the file is first sent to a service that scans it for malware. If there is no malware detected then the file is saved, if there is malware detected then the operation is aborted and the user informed – a simple, well-defined scenario.  

So why implement this as a microservice? Why not just embed the code inside the application? After all, creating and running a microservice does come with an overhead.  

In a simple case, embedding is a viable approach – the code is embedded inside the application and works. But as you develop more applications that require this logic, you start to duplicate code, which can be more work to maintain. And it can incur higher maintenance and validation costs as you need to upgrade the whole application to apply changes to that one feature.  

But simplified maintenance is only one of the benefits a microservice can bring. What are the other benefits?  

The benefits of a microservice  

Scaling  

Continuing with the malware checker example, let’s look at scaling. Your application copes well with a single user uploading a file, but what happens when you have 100 users uploading files simultaneously? Or 1,000? Or 10,000? The worst-case scenario is that it can consume the compute capacity of your application server, preventing anyone else from using it. But that’s ok – this is something you can address:  

• You could scale out the application by adding more servers. But these applications are usually resource-hungry – spinning up a whole new server just to scan for malware isn’t typically cost-efficient and can involve start-up delays.  
• You could add a queuing system to throttle the processing – but this could have a negative impact on the user’s experience, or even prevent them from working.  

With microservices, depending on how you implement your service, you can apply scaling on-demand with no changes to the consuming applications themselves. As your user requests go up, new instances of the service are created, and as the requests go back down, the extra services are destroyed – with no user intervention. Due to the small nature of a microservice, scaling up/down is quick in comparison to larger application servers.  

Modern frameworks and tools (such as AWS [Amazon Web Services] Lambda, Kubernetes) provide this as a standard behavior – you just need to specify the rules for scaling your service.   

Impact of failure and the radius blast 

No one likes to talk about failures in their products, but we are only human and despite our best efforts, things can go wrong. And even though they add an extra level of complexity to your systems, microservices can help to manage those failures when they occur, by reducing the blast radius when the worst happens using built in safety features like the circuit breaker pattern, bulkhead pattern or service registry. These approaches to minimize blast radius are the hallmark of modern applications.   

We had an example of this at IDBS with some document conversion code using third-party libraries. Most of the time this worked correctly, but document conversion can be quite volatile, occasionally a user would upload a “bad” file that would break the code in a spectacular way, killing the entire application server. This was impactful on system stability as it affected everyone on the server, rather than just those people doing conversions. By moving this code out into a microservice we were able to limit the blast radius of those failures to just the conversion process and the application server saw improved stability as a result.   

And as a bonus, we were also able to reduce the load on the application server as document conversion can be CPU and memory intensive, also contributing to system stability.   

Controlled upgrades  

Even though your service is doing one thing, and doing it well, it will require upgrades and new releases – it could be to apply security fixes, implement new features, or update libraries (including malware definitions!).  

To most companies, upgrading their services or applications is not an issue, but when you are dealing with regulated environments, the impact of any application change must be assessed, and verification needs to be performed to ensure the system is operating as expected after the change. The change management and reverification processes can be expensive – especially if you are upgrading the entire application, just to fix a defect.  

Microservices can help to reduce the costs associated with upgrades as you have a significantly reduced surface area of change, meaning only a small subset of the initial qualification activities may need to be performed.  

The microservice can be upgraded, with minimal or no downtime due to patterns such as rolling upgrades, without any change to the applications themselves.  

And because the change is restricted to just that service, the verification only needs to be done on the function using the service, nothing else. The key to achieving this is through a REST API (Application Programmer Interface) design (which includes automated testing of the API gateway).  

All the calling applications need to know is the address (URL) to call, and the data it expects – it doesn’t care about the actual implementation itself. This enables you to isolate the service from the main application, meaning you can change the service without changing the application – less to verify. And with API versioning the service can have new features added without breaking the behavior of the existing API.  

We’ve given you quite a bit to think about! In our next blog in this two-part series, we’ll dive into the deployment and management of microservices. Stay tuned! 

Discover how the cloud can help you leap ahead.