Welcome!

@DevOpsSummit Authors: Liz McMillan, Elizabeth White, Pat Romanski, Yeshim Deniz, SmartBear Blog

Related Topics: @DevOpsSummit, Microservices Expo, @CloudExpo

@DevOpsSummit: Blog Feed Post

Software Design with #Microservices | @DevOpsSummit #DevOps #APM #DX

Microservices embody both engineering and operational elements within its design

Microservices and the Revival of Software Design
By JP Morgenthal

Back in February of 2017, Andrew Clay Schafer of Pivotal tweeted the following: “seriously tho, the whole software industry is stuck on deployment when we desperately need architecture and telemetry.” Intrigue in a 140 characters. For me, I hear Andrew saying, “we’re jumping to step 5 before we’ve successfully completed steps 1-4.”

Microservices is an industry response to the need for more design in what we are putting into this pipeline.

I have to agree with Mr. Shafer that it does seem like the IT industry has a fascination with the part of the process that releases new capabilities into production. I personally hear the words “continuous delivery (CD)” at least 3-4 times a day. However, CD is the result of multiple iterations on a delivery pipeline to remove bottlenecks and consistently optimize and improve. Enterprises that believe they can get this right on the first attempt will be at a very high risk for failure.

I believe a key driver enabling users to make this leap is the emergence of the microservice. Because microservices embody both engineering and operational elements within its design, it’s possible for businesses to just focus on the operationalization of a microservice without even requiring any engineering effort. For example, operations can take an existing application component and package it up in a container (e.g., Docker) and deploy ten instances of that container.

This now suffices in some businesses as a microservice. However, it’s not really a microservice, it’s just a repackaged application component that now is easier to manage and deploy. I don’t mean to belittle this effort. The ability to automate management and deployment of existing applications goes a long way to reducing IT overhead. However, to Andrew’s point, it’s missing the architecture and telemetry.

Microservices: A Key Element of DevOps Strategy
The last few decades of software engineering have heavily emphasized design without equal consideration for operationalization of the software being developed. As a visualization, perhaps you have seen the meme with the young girl and the house on fire in the background with the text, “it worked fine in development.” That’s because it’s easy to make a distributed application work in a properly engineered development environment; it’s when we release it into production (the wild?) that we begin to see its flaws.

The response to the above trend has been the emergence of DevOps and a focus on adopting lean principles that facilitate rapid and continuous deployment of small numbers of changes. The rationale behind this is sound; limit the number of changes in control variables, leverage an automated and highly-repeatable process that has been thoroughly tested to push into production, and lower overall risk.

However, to Mr. Shafer’s point, it seems there is a bit of extremism that has swung the pendulum too much to the side of operationalization without having first mastered the art of the design. I believe the results of this effect can be summarized as moving garbage faster into production. I also believe microservices is an industry response to the need for more design in what we are putting into this pipeline.

All distributed computing archetypes recognize deployment architecture in some way, shape or form, but microservices is really the first of these distributed object computing archetypes to address packaging and distribution as a first-class attribute of the design goals. Isolation, decentralized data management and implicit tolerance for failure are central design goals for microservices. However, the key is to design the microservices in such a way as to amplify the business value of the entity, fulfilling the second part of Mr. Shafer’s statement.

In the past we have taught architects to think component design. But components are a part of something larger and don’t have value outside of the larger entity. For example, a gear is a component of an engine. The engine needs the gear to operate, but the gear has little value outside of the engine. We must now teach architects to think in terms of designing services, which have innate value without being part of something larger, but still can participate in a larger context, increasing it’s value. Hence, the service can be part of a larger application, or it can simply deliver on a single goal.

Microservices, then, are an integral and key element of any DevOps strategy. It is a common model that application development and operations can share and clearly establishes deployment boundaries and pathways. For engineering, the microservice represents a bounded set of business logic and data supporting a business capability. For operations, the microservice represents the unit of deployed business capabilities.

The post Microservices and the Revival of Software Design appeared first on XebiaLabs.

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.

@DevOpsSummit Stories
Five years ago development was seen as a dead-end career, now it’s anything but – with an explosion in mobile and IoT initiatives increasing the demand for skilled engineers. But apart from having a ready supply of great coders, what constitutes true ‘DevOps Royalty’? It’ll be the ability to craft resilient architectures, supportability, security everywhere across the software lifecycle. In his keynote at @DevOpsSummit at 20th Cloud Expo, Jeffrey Scheaffer, GM and SVP, Continuous Delivery Business Unit at CA Technologies, will share his vision about the true ‘DevOps Royalty’ and how it will take a new breed of digital cloud craftsman, architecting new platforms with a new set of tools to achieve it. He will also present a number of important insights and findings from a recent cloud and DevOps study – outlining the synergies high performance teams are exploiting to gain significant busin...
Enterprise architects are increasingly adopting multi-cloud strategies as they seek to utilize existing data center assets, leverage the advantages of cloud computing and avoid cloud vendor lock-in. This requires a globally aware traffic management strategy that can monitor infrastructure health across data centers and end-user experience globally, while responding to control changes and system specification at the speed of today’s DevOps teams. In his session at 20th Cloud Expo, Josh Gray, Chief Architect at Cedexis, covered strategies for orchestrating global traffic achieving the highest-quality end-user experience while spanning multiple clouds and data centers and reacting at the velocity of modern development teams.
In IT, we sometimes coin terms for things before we know exactly what they are and how they’ll be used. The resulting terms may capture a common set of aspirations and goals – as “cloud” did broadly for on-demand, self-service, and flexible computing. But such a term can also lump together diverse and even competing practices, technologies, and priorities to the point where important distinctions are glossed over and lost.
When shopping for a new data processing platform for IoT solutions, many development teams want to be able to test-drive options before making a choice. Yet when evaluating an IoT solution, it’s simply not feasible to do so at scale with physical devices. Building a sensor simulator is the next best choice; however, generating a realistic simulation at very high TPS with ease of configurability is a formidable challenge. When dealing with multiple application or transport protocols, you would be looking at some significant engineering investment. On-demand, serverless computing enables developers to try out a fleet of devices on IoT gateways with ease. With a sensor simulator built on top of AWS Lambda, it’s possible to elastically generate device sensors that report their state to the cloud.
CIOs and those charged with running IT Operations are challenged to deliver secure, audited, and reliable compute environments for the applications and data for the business. Behind the scenes these tasks are often accomplished by following onerous time-consuming processes and often the management of these environments and processes will be outsourced to multiple IT service providers. In addition, the division of work is often siloed into traditional "towers" that are not well integrated for cross-functional purposes. So, when traditional IT Service Management (ITSM) meets the cloud, and equally, DevOps, there is invariably going to be conflict.