BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Disposable Microservices

Disposable Microservices

Leia em Português

This item in japanese

Bookmarks

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 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
Style

BT