Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan

Related Topics: @DevOpsSummit, Microservices Expo, @CloudExpo

@DevOpsSummit: Blog Feed Post

The Microservices Pattern By @DavidSprott | @DevOpsSummit [#DevOps]

Microservices is a specialization of SOA that has applicability to a relatively narrow problem space

For those of us that have been practicing SOA for over a decade, it's surprising that there's so much interest in microservices. In fairness microservices don't look like the vendor play that was early SOA in the early noughties. But experienced SOA practitioners everywhere will be wondering if microservices is actually a good thing. You see microservices is basically an SOA pattern that inherits all the well-known SOA principles and adds characteristics that address the use of SOA for distributed, finer grained software services. And like all patterns, microservices are not applicable to all situations, and it's very important to understand the cost/benefit equation. Those folks that are heralding microservices as the "new SOA" or "the right way to do SOA" are flat wrong. Microservices is a specialization of SOA that has applicability to a relatively narrow problem space.

Componentized Services and Decentralized Data Management.

Capability based services that have reduced dependencies and single point responsibility for data has been a widely used SOA pattern. What's different with microservices is the decentralization of data management and encapsulation of the data in the service component. This is a useful pattern for services that can really own the data AND have high probability of churn in the service information model. The reduced horizon of change will be highly effective in responding to continuous business evolution.  But there's a serious cost to this, and Fowler et al surround the distributed data management advice with caveats.  They say, "Decentralizing responsibility for data across microservices has implications for managing updates. The common approach to dealing with updates has been to use transactions to guarantee consistency when updating multiple resources. . . . Using transactions like this helps with consistency, but imposes significant temporal coupling, which is problematic across multiple services. Distributed transactions are notoriously difficult to implement and . . . as a consequence microservice architectures emphasize transactionless coordination between services, with explicit recognition that consistency may only be eventual consistency and problems are dealt with by compensating operations."

Anyone who has dipped their toe in to this complex and murky pool knows that you do distributed data only when there is a real business requirement that demands this level of sophistication. In the typical enterprise environment there's a requirement for a range of SOA relevant data patterns. Distributed data is just one of many.

Decentralized Governance

The vision of microservices is very reasonably to facilitate heterogeneous technology platforms. But the Fowler guidance goes much further. "Perhaps the apogee of decentralised governance is the build it / run it ethos popularised by Amazon. Teams are responsible for all aspects of the software they build including operating the software 24/7. Devolution of this level of responsibility is definitely not the norm but we do see more and more companies pushing responsibility to the development teams.

"
But you don't have to be a Luddite to think that there are elements of governance that need to be centralized; and I'll bet are standardized in Amazon. For example, at a basic level security, logging, reference data and return codes, contract and API meta data and data management (see above), life cycle management etc. But in our practice we also see massive advantages in standardization of much of the (platform independent) architecture runway, SOA patterns etc. The advantages are not just about productivity and quality, which are considerable. They also deliver consistency of approach that has many less tangible benefits in terms of skills and resources, knowledge sharing and integrity of the delivered solutions, while still supporting heterogeneous target platforms. Perhaps this demonstrates the divide between the architect and developer viewpoints. And I have seen far too many enterprises getting into deep water because they have allowed the pendulum to swing too far towards developer independence.  

The concept of microservices is clearly creating much interest and confusion. I commented on the Newman book in an earlier blog that the author didn't seem to understand the difference between a pattern and a process. And perhaps this is the issue with microservices. The concept is essentially about decentralization and distribution, creating freedom of action for developer led teams that deliver something useful for (probably) a narrowly defined set of users. It all looks good in terms of ticks in the "project delivered" box. But it also looks remarkably tactical. And as I commented in my recent blog, lack of consistency leads to inability to govern and increased time to market. And my guess is that microservices, in the way they have been defined, will lead down a very similar path.

Nonetheless, there are some useful aspects to microservices. DevOps specialists are seeing real benefits from smaller units of deployment. Promotion of some of the basic elements such as componentization, automation and evolutionary design are a good thing. But adopting the microservices characteristics as a unified pattern as described is really only applicable to a narrow problem space. And as soon as you adopt the characteristics piecemeal, you have to reassess the cost/benefit. I expect that the widespread interest in microservices will lead to it morphing into a simpler, less complex pattern that does address a wider problem space. But surprise, surprise, we solved that a long time ago, and all we are doing is renaming highly independent Capability based services as microservices!

References: Microservices, Lewis, Fowler, March 2014

More Stories By David Sprott

David Sprott is a consultant, researcher and educator specializing in service oriented architecture, application modernization and cloud computing. Since 1997 David founded and led the well known think tank CBDI Forum providing unique research and guidance around loose coupled architecture, technologies and practices to F5000 companies and governments worldwide. As CEO of Everware-CBDI International a UK based corporation, he directs the global research and international consulting operations of the leading independent advisors on Service Oriented Application Modernization.

@DevOpsSummit Stories
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
This session will provide an introduction to Cloud driven quality and transformation and highlight the key features that comprise it. A perspective on the cloud transformation lifecycle, transformation levers, and transformation framework will be shared. At Cognizant, we have developed a transformation strategy to enable the migration of business critical workloads to cloud environments. The strategy encompasses a set of transformation levers across the cloud transformation lifecycle to enhance process quality, compliance with organizational policies and implementation of information security and data privacy best practices. These transformation levers cover core areas such as Cloud Assessment, Governance, Assurance, Security and Performance Management. The transformation framework presented during this session will guide corporate clients in the implementation of a successful cloud solu...
So the dumpster is on fire. Again. The site's down. Your boss's face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke. Yes, we know this is a developer's fault. There's plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone's job. But we're civilized now. Sort of. So we call them post-incident reviews. Fires are never going to stop. We're human. We miss bugs. Or we fat finger a command - deleting dozens of servers and bringing down S3 in US-EAST-1 for hours - effectively halting the internet. These things happen.
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
This sixteen (16) hour course provides an introduction to DevOps, the cultural and professional movement that stresses communication, collaboration, integration and automation in order to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster.