Welcome!

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

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
You want to start your DevOps journey but where do you begin? Do you say DevOps loudly 5 times while looking in the mirror and it suddenly appears? Do you hire someone? Do you upskill your existing team? Here are some tips to help support your DevOps transformation. Conor Delanbanque has been involved with building & scaling teams in the DevOps space globally. He is the Head of DevOps Practice at MThree Consulting, a global technology consultancy. Conor founded the Future of DevOps Thought Leaders Debate. He regularly supports and sponsors Meetup groups such as DevOpsNYC and DockerNYC.
The DevOps dream promises faster software releases while fostering collaborating and improving quality and customer experience. Docker provides the key capabilities to empower DevOps initiatives. This talk will demonstrate practical tips for using Atlassian tools like Trello, Bitbucket Pipelines and Hipchat to achieve continuous delivery of Docker based containerized applications. We will also look at how ChatOps enables conversation driven collaboration and automation for self provisioning cloud and container infrastructure.
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight and has been quoted or published in Time, CIO, Computerworld, USA Today and Forbes.
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with extensive global expertise as a strategist, technologist, innovator, marketer, and communicator. For over 30 years across five continents, he has built success with Fortune 500 corporations, vendors, governments, and as a leading research analyst and consultant.
The current environment of Continuous Disruption requires companies to transform how they work and how they engineer their products. Transformations are notoriously hard to execute, yet many companies have succeeded. What can we learn from them? Can we produce a blueprint for a transformation? This presentation will cover several distinct approaches that companies take to achieve transformation. Each approach utilizes different levers and comes with its own advantages, tradeoffs, costs, risks, and outcomes.