How micro should a microservice be?
Containers

How micro should a microservice be?

Microservices are one of the hot new trends in application development. A big part of their appeal is the promise of enabling developers to create applications that are more robust, secure, flexible, and scalable.

But is a microservice-based architecture right for your organization? How much work is involved in switching to microservices? And how micro should a microservice actually be?

 

Monoliths vs Microservices

According to a recent paper by Google on the subject, a monolithic application can be described as “a single deployable unit, e.g. a single WAR file in Java or a single Web Application/Web Site in .NET.”

AWS Chief Architect Glenn Core talks competition and the future. Check out: How Microservices break down legacy monoliths

“They are usually built in three parts: a client­side user interface layer, and a server­side application. They are usually long­lived, and are of critical importance to the health of the business. Because of the complexities, they have wide and deep class hierarchies, and many interdependencies between them.”

The problems with monoliths include:

  • Slow to change; even the smallest changes must be done to the whole application, which must then be redeployed
  • Complicated; large, legacy applications are hard for developers to understand in their entirety and often feature code written by developers no longer at the company
  • Brittle; small changes can break the entire application, and the problem can often be hard to find.
  • All of the above makes scaling difficult.

“It’s almost impossible for developers to master the entire code [within a monolithic application] due to the size of it,” says Mos Amokhtari, Regional CTO at CA Technologies. “There are too many dependencies when code is this large and so when a change is implemented, the odds of ‘breaking something’ are high.”

So, how to fix the issue of monolithic applications? One answer is the idea of microservices; breaking down these large beasts into discreet, easily chopped and changed components that exist independently of one another, but come together to create the whole.

Adrian Cockcroft, formerly Cloud Architect at Netflix, is credited as defining a microservice:

“Microservices are a loosely coupled Service-Oriented Architecture (SOA) with bounded contexts.”

The white paper from Google provides a slightly longer definition as a process of “modularizing a system into small services that provide well­defined, narrowly scoped APIs. Each microservice is supposed to be self­contained; they do not share a data layer, giving them complete autonomy. Each one may have its own datastore and load balancer.”

The benefits include:

  • Easier and speedier application development
  • Increased uptime as faults are less likely to affect the whole system
  • Allows for individual services to be written in any language and the technology stack that’s most appropriate for its development

“Microservices enable organizations to achieve greater agility,” says Dmitri Tcherevik, Chief Technology Officer at Progress. “They can be continuously updated and redeployed, each on its own schedule. For example, if an organization needs to update a new user on-boarding flow in order to increase user retention, the change can be implemented and deployed in production within weeks or even days. An application built on microservices offers a distinct competitive advantage.”

 

While some may say this is simply a repackaging of Service Orientated Architecture (SOA), microservices do differ slightly.

“At the application architecture level, they are similar,” explains Tcherevik. The difference is in the granularity of deployment units.

“It is common for many services in the SOA architecture to be bundled and deployed as monoliths, but each microservice is an independently deployable unit.”

Switching to microservices is a natural next step after moving to the Cloud. Where lifting and shifting entire monoliths requires computing capacity geared for peak workloads, microservices enable organizations to make better use of the elastic capacity allocation and flexible pricing as they can be deployed and scaled independently. But it also feeds into the ethos of DevOps and Agile.

“An organization that is considering the benefits of a DevOps and continuous delivery approach to their software development should be looking at microservices as a number one priority in this transition,” says John Pocknell Senior Product Manager at Quest.

“When you consider that with a microservices approach, an application that used to consist of thousands of lines of code can now exist as a collection of nimble microservices, which can consist of only 100 lines of code each, the simplicity and agility becomes very apparent.”

 

Should every company be looking to switch to a Microservice architecture?

While Cloud and microservice transformations are linked and feed into one another, they should be evaluated independently, according to Pocknell, as switching to microservices is “much more difficult” than moving to the Cloud.

And while there are benefits towards moving to a microservice-based architecture, like any new technology it is not a magic bullet. There are trade-offs that come with any such major transformation.

“There are serious challenges and changes that come out of breaking up a monolith into microservices,” says Pocknell. “Whilst the maintenance of individual applications is made simpler as a result of a microservices infrastructure, ensuring total visibility and monitoring of a myriad of interconnected services can result in a different form of complexity without the proper tools in place.”

“In truth, many organizations are either not ready for it from an organizational structure or engineering standpoint, or will not benefit from the transformation, and might actually lose on efficiency and agility due to added complexity.”

He adds that during such a transition, IT teams need to consider services will be tested, monitored and measured, secured, backed up, consumed by other subcomponents (for example latency), and how the whole system reacts in the event of one service failing.

 “Organizations should ensure that they fully understand their core applications and have a clear idea about what the specific business benefits will be as a result of the transition.”

The decision whether to break something down into a series of microservices must be made on a per application basis, according to Progress’ Tcherevik.

“Business applications that support multi-channel end user engagement can benefit from the greater agility offered by microservices. Any application supporting dynamic business processes is also a good candidate. Legacy applications supporting static business processes and a predefined number of delivery channels may not benefit as much.”

 

How to move away from Monolinths

Instead of a ‘Big Bang rewrite’, the best way to move your company away from monolithic systems to micro ones is to take a gradual approach; taking the whole and breaking it down bit by bit and rebuilding it in a piecemeal fashion.

“Start small and grow by iteration is my advice,” says CA’s Amokhtari. “Providing training and sharing the company vision are also essential to make sure teams have a common understanding of the objectives. Working towards making an impact will give teams a greater sense of purpose towards the company goals.”

As the number of services grows, he says, monitoring can become more complex, so a clear map of your services is mandatory, and he recommends automation wherever possible to keep up with the pace of delivery.

Tcherevik of Progress recommends an approach known as ‘strangling the monolith’:

“When a new module must be created or existing module must undergo significant changes, this module can be implemented as a microservice and deployed side-by-side with the monolith. An API gateway can be used to route requests in a way that is transparent to other modules using the service.”

But, he argues, there is more to such a move than mere technical components.

“Re-engineering an application around microservices must be accompanied by a company reorganization. It is not possible to change the application architecture without changing the structure of the human organization supporting it and the development operations processes.”

“Organizations supporting monolith applications are often structured by function: front-end, back-end, testing, DevOps, and others. It is typical for microservices to be developed, deployed, and managed by cross-functional small “two pizza” [8-10 people] teams.”

 

What is the right size for a Microservice?

At this year’s Alfresco DevCon, Brian Remmington, Chief Architect at Content Alfresco, said his own company’s Microservice transformation wasn’t about breaking everything down into the smallest possible chunks.

“I tend to avoid the use of ‘Microservice’; we’re not really aiming at microservices, we’re aiming at right-sized services,” he said. “There's no massive push for us to discard all parts of our current architecture and rebuild it in a microservice architecture. We want to go more towards that direction, but in a pragmatic kind of way.”

But what is the right size service?

Glenn Core, Chief Architect at AWS, told IDG Connect last year that a microservice should be “something that you can completely re-write in under two weeks”.

Tcherevik of Progress thinks the answer is as much a business decision as it is a technical decision; “The ‘right size’ is big enough to support a few steps in a business workflow that can be changed independently of other steps.”

CA’s Amokhtari also can’t give a definitive answer beyond ‘it depends’; “The size of the microservice is defined by a combination of the business goal and the fact that it should be built and maintained by a team of less than 10 people. One team can handle several microservices but one microservice should be handled by one team to preserve its integrity.”

 

PREVIOUS ARTICLE

«Testing the waters: The value of ethical hacking for business

NEXT ARTICLE

Are you at risk from Amazon’s S3 bucket problem?»
author_image
Dan Swinhoe

Dan is Senior Staff Writer at IDG Connect. Writes about all manner of tech from driverless cars, AI, and Green IT to Cloudy stuff, security, and IoT. Dislikes autoplay ads/videos and garbage written about 'milliennials'.  

  • twt
  • twt
  • Mail

Recommended for You

phil-muncaster

How a Washington crackdown on Huawei could backfire for everyone

Phil Muncaster reports on China and beyond

dan2

5G is over-hyped and expectations need reining in

Dan Swinhoe casts a critical eye on the future

keri-allan

What can we learn from tech initiatives in the Middle East?

Keri Allan looks at the latest trends and technologies

Our Case Studies

IDG Connect delivers full creative solutions to meet all your demand generatlon needs. These cover the full scope of options, from customized content and lead delivery through to fully integrated campaigns.

images

Our Marketing Research

Our in-house analyst and editorial team create a range of insights for the global marketing community. These look at IT buying preferences, the latest soclal media trends and other zeitgeist topics.

images

Poll

Should the government regulate Artificial Intelligence?