Explaining microservices – We accept the challenge!

Last time, we talked to you about the rising popularity of edge computing. If you remember, we discussed how IoT, AI and 5G are contributing to the demand for compute to take place at, or near, the source to deliver faster and more powerful processing abilities.

From a connectivity perspective, IoT and edge computing are all about interconnecting data from multiple applications to deliver insights, and it is this distribution construct that has challenged traditional monolith architectures because it was not established to deliver the speed and agility that these technologies require. This is where microservices step in.

The microservices style of architecture is aimed at expediting the process between development and code deployment. Instead of applications existing in a single monolith, microservices house individual components, organised as service sets around business capabilities. They are loosely coupled so that upgrades, changes and additions can be done individually without affecting the whole system. Essentially, creating building blocks to deliver a complete product.

In the case of implementing IoT use cases, this architecture is a natural complement to manage the broad distribution of data sources. Instead of information coming in centrally, where use cases are developed, tested and rolled out as a packaged application, microservices allows modular code blocks to be updated and plugged in as needed.

Take manufacturing for example, you use a collection of IoT devices to track the performance and usage of your machines. In order for that data to be meaningful for stakeholders, it needs to connect with an IoT hub, data centres, cloud services, business intelligence tools and other network applications. Under a monolith architecture, a simple supplier change will touch each application for that update to take effect. Under microservices, you can access the component where that information is held, and perform the necessary changes without it affecting the whole system.

The ability to update, change or triage individually rather than across the entire application gives more flexibility to scale, evolve and deploy frequently. Ultimately, faster speed to market. This offers great promise to those who have poured countless hours accessing multiple systems to make seemingly simple changes. However, microservices is a dramatic shift away from traditional constructs. You want to make sure you’ve explored all the possibilities of your current setup before embarking on this journey because poor planning has seen many leading companies fail in its shift to a microservices environment. Not only are processes disrupted, networks can be impacted, latency increased, and security compromised, backfiring to deliver the efficiency it aims to deliver. 

In the case of the example above, a name change sounds simple in nature but if your processes haven’t identified the flow-on effect that change will have across your applications, you’re likely to have a lot of frustrated and tired workers trying to solve the issue.

Before shifting to microservices, here’s the lowdown on some critical factors you need to look at:

• 1. Security. Microservices tend to open up the network because each service is trying to talk and respond to a request at any time, any location and on any device. Depending on the specific request, individual components are not always aware, or need to be aware, of the details of this interaction and this can create holes that expose security vulnerabilities and compromises the network. You need to be proactive and look at restricting control and security on each service.
• 2. Unintended Network Consequences. As the number of microservices increase, each event or API call can trigger a number of corresponding events in other microservices that can multiply exponentially depending on the overall architecture. This can have a corresponding impact on the performance of the network in a non-linear fashion. i.e. performance degradation is sporadic and unpredictable making troubleshooting and support even harder. Orchestration and automation become critical tools for any network.
• 3. Domino effect. You’re now working in a distributed system so it is much more likely that some part of the system will fail at some point, and that can cascade onto other services. Unexpected backlog issues and congestion can impact your network so make sure your processes are very well planned and thought out. A shift to microservices will have implications across the technology team so expect the effort to operationalise to be high.
• 4. Catering for more. Microservices use a lot of new technologies and you need to understand the impact this will have across your existing tech stack - and be vigilant that you don’t add unnecessary pressure on your network.
• 5. It’s not a one size fits all solution. There are some apps that are just not suited to microservices and could create a new world of headaches if you try and make them fit. Spend the time to understand what business problems you’re trying to address to determine if microservices is the right fit.