Apps

Detours on the way to microservices

MicroservicesIn 2008, I first heard Adrian Cockcroft of Netflix describe microservices as “fine-grained service oriented architecture.” I’d spent the previous six years wrestling with the more brutish, coarse-grained service-oriented architecture, its standards and so-called “best practices.” I knew then that unlike web-scale offerings such as Netflix, the road to microservices adoption by companies would have its roadblocks and detours.

It’s not quite ten years later, and I am about to attend IBM InterConnect, where microservice adoption by business seems inescapable. What better time to consider these detours and how to avoid them?

Conway’s law may be bi-directional

Melvin Conway introduced the idea that’s become known as Conway’s Law: “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

But I saw it occur in reverse: When enterprise software organizations first decide to adopt microservices and its disciplines, I observed development teams organize themselves around the (micro-) services being built. When constructing enterprise applications by coding and “wiring up” small, independently-operating services, the development organization seemed to adjust itself to fit the software architecture, thereby creating silos and organizational friction.

More than the sum of its parts

When an organization first adopts microservices in its architecture, there are resource shortages. People who are skilled in the ways of microservices find themselves stretched far too thin. And specific implementation languages, frameworks or platforms can be in short supply. There’s loss of momentum, attention and effective use of time because the “experts” must continually switch context and change the focus of their attention.

As is usually the case with resource shortage, the issue is one of prioritization: When there are hundreds or even thousands of microservices to build and maintain, how are allocations of scarce resources going to be made? Who makes them and on what basis?

The cloud-native management tax

The adoption of microservices requires a variety of specialized, independent platforms to which developer, test and operations teams must attend. Many of these come with their own forms of management and management tooling. In one case, I looked through the list of management interfaces and tools for a newly-minted, cloud-native application to discover more than forty separate management tools being used. These tools were covering: the different programming languages; authentication; authorization; reporting; databases; caches; platform libraries; service dependencies; pipeline dependencies; security threat model; audits; workflow; log aggregation and much more. The full list was astonishing.

The benefits of cloud-native architecture do not come without a price: organizations will need additional management tooling and the costs of becoming skilled in those management tools.

Carrying forward the technical debt

When a company embraces cloud migration or digital transformation, a team may be chartered to re-architect and re-implement an existing, monolithic application, its associated data, external dependencies and technical interconnections. Too often, I discovered that the shortcuts and hard-coded aspects of the existing application were being re-implemented as well. There seemed to be a part of the process that was missing when the objective was to migrate an application.

In an upcoming blog post, I’ll consider some of the common detours and look to what practices and technologies are being used to avoid them.

Join me and other industry experts as we explore the world of microserivces at IBM InterConnect on March 19 – 23, 2017.

 

Share this post:

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Apps Stories

Why would a cloud expert be interested in a new DevOps tool?

I have been working on cloud infrastructures since before the hype over cloud computing. I have watched as the cloud matured from just being a way to get cheap Linux instances into a set of services that are literally changing the way we deliver IT forever. I have also witnessed the challenges enterprises face when […]

Continue reading

Five cloud coding tips from an Agile development team

When it comes to developing code for cloud applications, I have learned that having basic ground rules helps to ensure efficient and secure code development.  Following these ground rules can yield higher quality code. I work with a team of exceptionally bright cloud application developers that provide cloud infrastructure for clients. The team has implemented […]

Continue reading

How did we develop software without Docker?

Software developers have used container technology for some time now, but why is Docker so darn popular? With Docker, a developer can use a command to build everything needed to run an application into a single package. Docker’s developers built its API to fit seamlessly into most development and deployment workflows. Remember when it was […]

Continue reading