Abstract

In cloud native architectures, large applications are created from loosely coupled microservices instead of being one monolithic entity. Microservices are small, autonomous, self-contained software components, organized around business domains, which means each part can be easily monitored, tested and updated without affecting the others, bringing greater business and operational speed and agility.

As microservices are integral to cloud-native architecture, it’s tempting to dismiss them as things that happen more or less ‘naturally’ in that environment. This is a dangerous assumption. All types of architectures have cons as well as pros, and organisations need a basic set of competencies in place before considering putting them into production.

Further, deploying microservices in a piecemeal fashion, rather than strategically, is an approach that will inevitably cost an organization dear in terms of time, money, agility and resources in the probably only slightly longer run.

Common errors include deploying technology for its own sake rather than to achieve a specific outcome. Becoming too tool-centric is another pitfall for the unwary – tools are the means, not the end. Those who create an exclusive infrastructure for each microservice will discover that approach rapidly becomes very costly while keep re-inventing the wheel for use cases that cut across capabilities is a pointless, resource-hungry process.

With a proper strategy in place, including good governance, enterprises can ensure microservices are a key enabler for their hybrid integration platform. They will be able to leverage the benefits of microservices architecture instead of potentially replacing an outdated monolithic applications environment with a newer but more expensive, less effective one.

Introduction – the multiple appeals of microservices

In cloud native architectures, applications are broken down into a collection of loosely coupled services encapsulated in software for some good reasons. Correctly deployed, microservices can bring some big business and operational benefits. This introduction is not exhaustive.

Each microservice can be updated and swapped in and out without impacting the others that together make up the application.

Microservices leverage DevOps methodologies and are easier to maintain and test because these processes don’t involve the entire application.

Microservices are organized around business capabilities and are usually owned by a small, expert team.

The attributes described above mean cloud native architectures can create, deliver and maintain large and complex applications far faster than their traditional equivalents.

Organizations can evolve their technology stack by following key principles, rather than be limited to a particular technical framework to build and use microservices.

Each microservice is exposed using a standard protocol for easy consumption and sticks to service orientation principles for publishing and discovery.

Microservices-based architecture is the evolution of service-oriented architecture (SOA) and has key attributes that SOA lacks:

  • SOA is reliant on the messaging protocols of enterprise service bus (ESB) for communication between an applications’ components in a centralized manner with protocols such as SOAP while microservices communicate using lightweight protocols such as REST APIs or binary protocols such as Protocol Buffers or Apache Thrift.
  • each microservice can be deployed and scaled independently of the others that make up the application.

There are a number of readily available, JavaScript code-centric, microservices frameworks, like Spring Boot or Node.js or Eclipse Vert.x, for developers to use out of the box.

Section 1

What could possibly go wrong?

Microservices have a lot more moving parts than traditional applications, and require new ways of working and new skill sets. Without a coordinated, strategic approach to building, deploying, running and maintaining microservices, organisations will not reap their full potential. In this section we have a brief look at some of the most common mistakes concerning microservices.

Technology is only part of the story

Moving to a microservices architecture is a fundamental shift in organizational mindset, team structure and organizational culture because these services rely on the DevOps methodology and deployment model.

As ever, cultural change and resistance to new ways of working present far more serious barriers to success than the technology per se.

Don’t get distracted by the tools

It’s easy to get caught up with mastering and using new tools and lose sight of the end goal. Tools are important but they are the means to an end, not the end in themselves. Despite persistent, collective wishful thinking in IT departments, there is no magic product, resource or tool that holds the key to universal success.

Remember, outside science projects, technology for its own sake never results in return on investment.

What are you trying to do?

Do not assume that microservices are always the best option in every situation. Start with the desired business outcomes and figure out the best way to deliver them rather than starting with figuring out possible uses for a new technology.

Reinventing the wheel

Having established that microservices are the best fit, it’s important to understand that not all microservices are created equal, and their function(s) need to be considered carefully.

Developers write code for the business logic of a microservice which works especially well for use cases with self-contained logic like applying tax rules or discounts, or to manage defined business entities such as customers’ profile or product information.

However, use cases frequently cut across various systems of record, connect to partners’ systems or extract data from a cloud-based service. Issues like logging, health checks, externalized configurations, metrics, and distributed tracing are among the architectural considerations for which developers tend to build custom solutions. If not governed, different teams tend to re-invent the wheel with similar solutions which is an expensive and slow way of working overall.

A service mesh provides most of these cross-cutting capabilities and can be leveraged as part of governed microservice architecture (see Section 2).

Skyrocketing costs from remote calls

As each microservice can scale independently, it needs its own infrastructure which can soon become extremely expensive. Also, services need to communicate with each other, but if the service is poorly designed this can involve many remote calls which slows network latency and processing.

Automation matters

Automation is very important if microservices are to deliver one of their biggest potential advantages – rapid provisioning. Inconsistent approaches (like reinventing the wheel as outlined above) and customization instead of repeatable configuration hamper or make automation impossible.

Knowing an integrator from a bus

Adopting a microservices architecture is part of an enterprise’s wider integration transformation. Almost all transformations will involve a hybrid-integration landscape, that is, a combination of a legacy and new integration tools and frameworks will co-exist. Knowing which approach is suited to which kind of microservice use case needs careful consideration from the start to decide whether an enterprise service bus (EBS), integration Platform-as-a-Service (iPaaS) or micro-integrator should be deployed and in what circumstances. We look at this in more detail in Section 2.

Section 2

How to succeed with microservices

As ever, any organization’s first step to the successful adoption of microservices is establishing clear business and operational outcomes. This doesn’t mean simply listing the usual top-level aims such as providing excellent customer experience, more efficient processes and operations, greater automation and higher profits – organizations need to dig down far deeper than that to build a useful microservices strategy.

 

Microservices are part of integration transformation

Although transforming integration typically doesn’t make high level list, it is foundational to the success of all digitalization programmes. In most enterprises, different integration tools and frameworks will co-exist to support legacy integration technologies which is known as a hybrid-integration landscape, which is best addressed by a hybrid integration platform (see this whitepaper). Microservices is a key enabler of a hybrid integration platform, as shown in the schematic below.

Hence drawing up a roadmap that translates the high-level goals into a detailed plan for microservices’ deployment is essential.

Culture, skills and organizational changes

Most of the work regarding the shift to using microservices is in preparation, ensuring that the microservices strategy is integrated with bigger integration and digitalization pictures at the macro level, but at the micro level it means ensuring there are enough developers in-house with the right skill sets, in a DevOps practice with appropriately structured teams.

This does not and cannot happen overnight – some companies are in-sourcing skills, that is retraining existing staff, as well as recruiting talent, but this is in short supply. A pragmatic option to accelerate progress and build confidence is to work with an expert partner that has a proven track record in transforming integration, DevOps practices and specifically in designing, building, deploying, operating and maintaining microservices.

In particular, such a partner will be able to speed things up, massively reduce errors and by bringing a high degree of automation to the software delivery process.

Assessing your current delivery environment and whether your teams, tools, architecture, culture, and governance are ready for taking software delivery to the next level.
 
Identifying needed improvements to your team structures, tools, architecture patterns, KPIs and SLAs, and governance policies and processes.
 
Crafting your roadmap for staged evolution to rapid, controlled software delivery to support accelerating rates of business change.
Selecting and implementing your initial delivery automation tools, practices, and scripts, along with a continuous improvement process.
 
Building automated governance into your delivery pipelines and processes.
 
Mentoring and training your staff on delivery automation and its critical relationships with collaboration, digital transformation, and solution architecture.

Its expertise will also help with identifying which legacy applications are candidates for shifting to microservices, because not all of them are. Too often we see legacy in a negative light, rather than as an enterprise’s key differentiator, built and evolved over many years.

Good governance is essential

As in all areas of digital transformation, it is hard to overstate the importance of governance when adopting a microservices architecture. It can play a key role in avoiding the pitfalls outlined in Section 1. For example, to establish and enforce standards and consistency in the way different teams approach microservices that cut across capabilities.

This avoids the expensive and unnecessary duplication of work if each team reinvents the wheel which, as mentioned, also makes automation difficult if not impossible and can impact interoperability. Governance can avoid mistakes, control costs and ensure fitment across the wider organization, by setting rules and standards before the adoption of microservices.

However, the best policies should accept decentralized governance regarding tools used for each microservice which can be determined by the teams that use them. It is crucial to establish best practice policies along with clear communication channels where accountability and effectiveness can be measured.

Microservice governance and management frameworks

As we mentioned in Section 1, a service mesh can be deployed to provide many cross-cutting capabilities and can be leveraged as part of governed microservice architecture. The mesh includes built-in support for network functions like resiliency, error checking, service discovery and more. This approach saves developers effort, enabling them to focus on business logic rather than network logic and processes. As it uses standardized network logic, a service mesh is language agnostic. Service meshes are similar to a micro-gateway, but they are entirely abstracted from the business logic.

As the schematic below shows, service meshes can integrate seamlessly with the Coupler, micro-integrator (explored in more detail below)

 
 

Knowing an integrator from a bus

Different integration tools and frameworks will co-exist to support legacy integration technologies in enterprises’ hybrid-integration landscapes. Different integration technologies are suited to certain situations. For example, where a microservices use case needs complex composition and orchestration within many integration points, then solutions like an enterprise service bus (EBS) or integration Platform-as-a-Service (iPaaS) can be used to build services.

However, as we outlined in the introduction, microservices-based architecture is the evolution of SOA which uses the messaging protocols of ESB for communication between an applications’ components. Microservices communicate using lightweight protocols such as Apache Thrift or REST APIs, hence it is advisable to move away from ESB and webservices and instead adopt an integration Platform-as-a-service (iPaaS) – in certain situations.

Propelled by the migration to the cloud, research published in August 2021 by The Insight Partners forecasts iPaaS will grow at 21.2% CAGR between 2021 and 2028, to more than $8.844 billion.

iPaaS isn’t a magic solution: There are many different ones in the market and it’s an onerous undertaking to work out which one best suits any given organization’s needs, given that each one is unique. Again, this is where an expert partner can be invaluable and accelerate the process. Torry Harris Integration Solutions (THIS) partners with the big three cloud hyperscalers (AWS, Microsoft Azure and Google Cloud) and, where appropriate, deploys Oracle Fusion as the iPaaS.

Where use cases are mostly self-contained but sometimes depend on data from external sources, then a micro-integrator framework is a better option. It offers the visual design flow of EBS or iPaaS plus microservices’ cloud-native attributes including containerization and scale.

Coupler is an example of a micro-integrator which can be containerized and deployed as a microservice (as shown below). Containers package an application with all the parts it needs, such as libraries and other dependencies, and ship them out as one package. Docker is a tool designed to make it easier to create, deploy, and run applications using microservices and containers.

 
 

Without this progression to modern integration practices and tools for microservices, integration will not be aligned with the wider digitalization effort within the company.

In conclusion

Microservices potentially have many advantages that can bring substantial business and operational benefits to an enterprise but, like all technologies, there is no automatic guarantee of success. Moving to a microservices architecture – and choosing the right candidate applications – is a strategic decision, which means enterprises need a strategy in place.

A piecemeal approach will be expensive and slow progress, which doesn’t mean an organization shouldn’t start small and expand microservices as it gains experience and expertise. The idea though is to build on what has been done rather than have to start afresh having learned some costly lessons.

As the right skills and experience are in short supply, with tough competition for them, most enterprises would be wise to choose an expert integration partner with a proven track record to work with its teams in this still evolving area.