Despite being an obsolete term a few years ago, “microservices architecture” is fast becoming one of the most popular ways to design software applications. Widely regarded for the agility it affords organisations in today’s fast-changing world, microservices allow organisations to break down large, monolithic applications into a set of loosely coupled services.

Yet, amid microservices’ growing popularity, organisations should not do it for fashion. One size doesn’t fit all and trying to follow in the footsteps of pioneers like Spotify and Netflix might not be feasible.

For example, one of the major challenges for established companies when adopting microservices is learning how to mix this architecture pattern with the many other architectural patterns already deployed in the enterprise. Additionally, companies need to learn how to manage the speed and flexibility that microservices fuel, as well as the complexity it creates.

>See also: Thinking outside the microservices box

To gain true value from microservices in 2018, business and IT leaders need to start by assessing business objectives and evaluating if the architecture can coexist with traditional applications, as well as current systems, business processes and operational and compliance imperatives, combined with their DevOps capability and maturity. For most organisations, it will mean complementing microservices with an API strategy.

Why microservices?

The microservices approach is in many ways a modern reincarnation of the decades-old idea of component-based development (CBD), and it also draws upon the principles of Service-oriented Architecture (SOA). Thanks to standardised containers, highly flexible cloud infrastructure and APIs—which tie apps, systems and devices together—microservices allow developers to break down monolithic apps into loosely coupled functions focused on supporting specific business processes. In so doing, organisations can be much more agile in responding to new market requirements, rolling out robust digital capabilities quickly and easily to customers, employees and partners alike.

From an IT perspective, the benefits are even clearer. Aside from the fact that microservices are faster to build, test and deploy, they also add reliability to the mix. If a fault occurs, for example, it will only affect users of that specific service rather than the entire IT stack.

>See also: APIs: Please use responsibly

Microservices are also easy to scale and can be changed, updated and deployed in a simple, automated manner. For developers, microservices mean greater flexibility and productivity, allowing them to independently develop and deploy services in smaller teams, and code in the languages and frameworks they’re most comfortable with.

The importance of an API strategy

However, organisations must also be aware that microservices aren’t a silver bullet. For one thing, this architectural approach creates an increasing number of services that can result in information barriers and service sprawl.

Additionally, it usually brings additional complexity for developers, who now have to mitigate fault tolerance and network latency, while dealing with a variety of message formats as well as load balancing. There’s also a danger of duplication of effort: teams must put extra resources into transparency and communication, especially in use cases spanning more than one service.

To help tame microservices complexity, organisations should implement an API strategy. APIs not only bridge the gap between microservices and traditional systems, they also make microservices easier to build and manage. With an API strategy, organisations can expose the functionality of microservices as products, which can lead to the creation of both internal and external business value.

>See also: Enterprise tech continues its rebirth in 2018

APIs can also overcome the significant costs associated with building point-to-point integrations between legacy systems and SaaS apps, enabling organisations to quickly plug and unplug microservices into their application networks, which connect digital assets and capabilities across the entire IT stack.

Firms like Spotify are taking this approach, using APIs to manage and connect microservices as part of a DevOps push to streamline business processes and create a more agile and responsive company, for example SKY has adopted a microservices architecture approach for which it uses Replaceability, Operability, Accessibility & Maintainability (ROAM) as its guiding principles.

It’s not all about those at the vanguard of technology innovation either; 130-year-old Unilever has built over 80 microservices to connect e-commerce applications with legacy systems around the world.

Thanks to an API-led connectivity approach, the global giant has been able to reduce development time and deploy 3-4 times faster to drive success. Other more traditional companies including high street lending giant Barclays and airline flydubai are reaping similar benefits from microservices by taking the same approach.

>See also: Mobile in the enterprise and the changing role of the CIO

Looking ahead

It’s important not to rush into microservices just because it’s what others are doing. Organisations that are heavily reliant on monolithic legacy deployments must do their research first to make sure that switching will be worth the disruption caused by re-engineering these applications. However, if they do, API-led connectivity is the only choice to manage the crucial integration piece effectively and minimise the risk of uncontrollable microservices sprawl.

In today’s uncompromising business climate, organisations need to take calculated risks to stand out from the crowd, get closer to customers and work more productively. As we enter 2018, more and more organisations around the world will look to a combination of microservices and API-led connectivity to do just that.

Sourced by Paul Crerand, director of solution consulting, office of the CTO, EMEA, MuleSoft