Apps

Detours on the way to microservices

Share this post:

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.

 

Add Comment
No Comments

Leave a Reply

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

More Apps Stories

Increase the business value of APIs

This post was co-authored by Danny Levenson, Senior Software Engineer, PointSource. Application Programming Interfaces, or APIs, define the data contract between two pieces of code. APIs used to be exclusively the domain of developers. In this post, I’ll show you how APIs provide the freedom for systems to evolve independently and create new opportunities for […]

Continue reading

Unlock the power of WebSphere z/OS on IBM Z

I’ve seen a lot of excitement from developers around the July 17th launch of the latest IBM Z hardware and software (z/OS), and justifiably so. There are clear, significant benefits of IBM Z, including its security, resiliency and performance characteristics that make it a platform worthy of running your mission-critical enterprise applications. And for all […]

Continue reading

Moodpeek measures mobile reputation with a Bluemix-based PaaS solution

According to Mobile Business Insights, mobile devices are the primary means of accessing digital information for consumer and business use. How are mobile users accessing information? Ninety percent of the time, it’s through mobile apps. Smart Insights states that consumer preference for mobile apps rather than mobile sites should be considered when defining a mobile […]

Continue reading