BT

Disposable Microservices

| by Mark Little Follow 14 Followers on Sep 13, 2015. Estimated reading time: 3 minutes |

Recently RedMonk's James Governor wrote an article as a precursor to a session he's giving at Dreamforce around the disposability of microservices. As James said, he had an epiphany moment during a recent conversation:

while improved infrastructure disposability is a significant reason for adopting containers, it is actually definitional to microservices

In essence, the now fairly well understood distinction between the cattle and pet approach to infrastructure (discussed by Randy Bias, InfoQ and others) can and should be applied to microservices.

Disposability has been a long time coming – I remember the aha when I first heard how Google dealt with hardware failures – by simply throwing out the offending boxes every once in a while, with no need to do anything immediate. At Google the software architecture meant that hardware became disposable. Today that architectural idea(l) is becoming a core design principle for Cloud Native software

The immutable infrastructure approach which has rapidly been growing in adoption, is a key aspect of the solution to disposability. Chad Fowler had this to say back in 2013 when his company was moving to adopt immutability for the first time and saw it as a way of solving many problems with upgrading infrastructure:

Need to upgrade? No problem. Build a new, upgraded system and throw the old one away. New app revision? Same thing. Build a server (or image) with a new revision and throw away the old ones.

Although as Mitchell Hashimoto said in our virtual panel session in 2014, immutability isn't a panacea for everything:

It has its benefits and it has its downsides. Overall, I believe it to be a stronger choice and the right way forward, but it is important to understand it is no silver bullet, and it will introduce problems you didn’t have before (while fixing others).

Whilst immutability today has been focused at the infrastructure level, James believes the pattern is applicable higher up the stack. Quoting from another earlier RedMonk article from Stephen O'Grady where Stephen asked what is the atomic unit of infrastructure in the future?

Containers generally and Docker [treat] the operating system and everything beneath as a shared substrate, a universal foundation that’s not much more interesting the raised floor of a datacenter. For containers, the base unit of construction is the application. That’s the only real unique element.

Others over the last few years have made similar assertions that microservices should be disposable without necessarily equating that to immutability. For instance, Kief Morris had this to say in an earlier article which although not specifically about microservices is still relevant:

With Continuous Delivery of software, it's safer to compile a given version of an application into a deployable artifact only once, and know that you are deploying and running a consistently built application in all environments. With an immutable server, you make each change to a base image, and then you know that all instances created from that image are consistent.

And we reported earlier this year how Salesforce's Pat Helland believes that immutability changes microservices and a lot more:

Many kinds of computing are “Append-Only”. Observations are recorded forever (or for a long time). Derived results are calculated on demand (or periodically pre-calculated). And: Normalization is for sissies!

So whilst immutability and microservices is something others have been thinking about and implementing for a while, the disposability epiphany James mentioned is a relatively less discussed area. Although as Galen Gruman and Alan Morrison mention it's certainly something that is a logical evolution of microservices and immutable architectures:

Think of MSA as almost-plug-and-play in-app integration of discrete services both local and external. These services are expected to change, and some eventually will become disposable. When services have a small focus, they become simple to develop, understand, manage, and integrate. They do only what’s necessary, and they can be removed or ignored when no longer needed.

James concludes with this:

So microservices must to be disposable. If a microservice fails or is superseded a better service, then simply dispose of the old one.

Perhaps 'must' is too strong a term? Or perhaps this is a pattern which other microservice developers already find themselves using or moving towards?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

JVM & AWS by Axel Fontaine

This is exactly what we offer at Boxfuse (boxfuse.com) for JVM and AWS users: immutable image generation in seconds, zero downtime blue/green deployments to AWS and deep Spring Boot and Dropwizard integration.

All instances are disposable and launched from fully-baked AMIs built in under one minute.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT