One thing that we’re very good at in IT is breaking new ground, coming up with ideas that work astoundingly well, getting broad adoption, then standardizing them for interoperability. When a new technology (looking at you, cloud) has problems with standardization and interoperability, we find a way around vendors’ reluctance to give you freedom of choice. For cloud, for instance, we found another great technology – containers – that greatly limits our lock-in to a given cloud vendor’s fare. Of course, whether standards or workarounds are the answer we arrive at, there are always wrinkles. Vendors are certainly not motivated by interoperability; they want your regular cash infusions, and interoperability could be more of a drain on them than a feed of new customers. Particularly in today’s environment, where vendors sometimes think that doing “to” customers is an acceptable substitute for doing “for” customers. We have to work around things like “embrace and expand,” which is still very real, and deploying containers to cloud A versus cloud B still has a bit of vendor-specific work, but we have enough to get it done.
As continuous integration (CI) has become critical to an increasing number of organizations’ IT processes, the time has come to do the same with CI tools. Standardization is a good first goal, but it is more difficult here than in many areas, because the topic is so broad. An app might be built in one tool and tested in another, or it might be built via the use of shell scripts while tested with a UI tool, etc. It is not an easy solution to build, but it is an idea whose time has come – particularly with the cloudification of the space. We now have full-on CI systems that are in the cloud, and which hook you in with custom instructions. We’ve already had one large DevOps vendor essentially tell their entire user base, “We’re moving you to the cloud, unless you pay these inflated fees,” and others that never offered options for traditional architectures at all.
Yet, we know apps move from in-house to cloud (and though it is uncool to mention, move back), and organizations are motivated by cost containment and mobility more than by what their chosen vendor wants them to do.
So, it is time for some bright company or OSS team to put together a standard and a tool that implements said standard. It will be a lot of work, to make portability between CI tools that came from widely disparate roots – some from build, some from test, some even from deployment. But we’ll be needing it. A while back, everyone was a Puppet shop. Now, it seems, everyone is an Ansible shop. In simple terms, everyone will inevitably be a [something else] shop, because nothing lasts forever. So, a tool providing CI mobility between tools will definitely have a market – smaller today, but eventually large. We don’t need Yet Another CI Tool, we need that portability.
I’m sure it’s coming. History does offer glimpses of the potential future, and we’ve seen this cycle before. I’m just saying, the time is now, not five years from now. We can target the OS of our choice and the cloud vendor of our choice, using containers to simplify the differences in host OS/vendor. The ability to use the CI tool of our choice is the logical next step.
I haven’t heard of a project or company working on this yet; if you have, drop me a link in comments or email (I prefer comments, so others can look at your suggestion too, but whatever works for you), and I’ll take a look. It would be cool to support this kind of effort, when it eventually comes about.
Every once in a while, it is a good idea to take stock of the environment and the market around us to determine if what we are doing is what we should be doing. I’m a developer, not a prognosticator, so these observations are simply based on my experience in the development world, along with a frank assessment of what’s changing, to try and offer some advice to my fellow developers. This week I’ll talk about embedded, but we’ll hit a bunch of application targets over the coming weeks.
Embedded development is, generally speaking, more low-level than most other modern programming practices. Considering the goal of embedded is to interface with the hardware, this is no surprise.
C/C++
And that brings us to the king(s) of the embedded hill. C, and to a lesser extent, C++ rule this roost. You will see a lot of talk about Python, and we’ll get to that in a minute, but for historical and performance reasons, C is still your best bet. If your DevOps tools support your Make variant – Ant, Maven, or whatever – it can be plugged directly into the DevOps process. Testing will still take extra steps. Since deployment is most often handled directly, that does not generally need extra steps, but, in some cases, it might. A lot of general guides claim C/C++ is “easy” to learn. I disagree with this assessment; newer languages tend to be more intuitive while retaining some of C’s better features, but it is, at this time, necessary to embedded development.
There’s a Reason (or Many) for That …
There are a lot of conflicting factors going into where embedded is headed in the future, so we’ll try to address them here.
Historically speaking, C/C++ have had better performance and smaller footprints than interpreted (even bytecode) languages. They are easier to code in than Assembly and supported by a ton of libraries to get work done; they struck the right balance for embedded. The weight of these developers and the legacy source code they created are part of the reason C/C++ are still on top.
But three things have caused a shift that will open up room for other languages to make headway into this space. Embedded devices are getting faster, and storage is getting both smaller and cheaper. That means that a less-efficient means is more viable. Arduino and other hobbyist embedded platforms have also come of age. It is now viable to pick up an embedded board and start prototyping over the weekend. These embedded environments are well-supported by newer languages, and, historically speaking, today’s hobby builders are tomorrow’s startups. This is pulling other languages into the mix far more frequently, particularly our next entry.
Python
Python is popular in almost every category of programming. It has been around long enough to lose the mantle of “language du jour,” and should be considered based on its strengths and weaknesses. Given that the newer wave of prototype systems is well-supported by Python, it is easy to maintain, and has a broad selection of libraries (often, ironically, written in C), it has gained clout in the embedded space. It doesn’t perform as well as C/C++, but modern embedded devices are of a class that this may not be as important (early embedded devices were high-performance tools, while IoT often has devices that don’t require anything like near-real-time), and hardware improvements make this less of a concern. Python’s popularity makes it relatively easy to work in to your DevOps toolchain, with targeting of embedded devices making deploy and test require extra steps … but that’s true for all of these languages, as it is a targeting feature, not a language issue.
Assembler/Assembly
In the end, we need machine code. Even bytecode (or p-code, if you prefer) interpreted languages execute their instructions in hardware, eventually. Because performance and space have long been issues in embedded development, assembly language has been a preferred tool for pieces of the development pie. While few developers use assembly language for everything, most embedded developers use it, at some point, to modify libraries or create targeted subroutines. Certainly not a “popular” language among developers, most of us buckle down and just do what we need to. Like C, assembly is normally built using a Make variant. These are easily integrated into DevOps toolchains to get reporting and results up to those dashboards that run a company’s agile efforts.
Others
There are a wealth of other languages in use on embedded platforms, most notably C#, but also newer languages like Rust. The environment is changing, and as the ramifications of terabyte SD cards and multi-core embedded boards start to sink in, they are worth watching. We are not that far off from having a desktop-quality computer in a board only a little larger than a credit card. That changes a lot of things. More room for data storage and processing, and the need for tools that are easier to use in these contexts.
Libraries
All languages use libraries to make development easier. We are past the days when coders wrote all of the functionality of their project. The tools that bring libraries into a project need to be incorporated into the DevOps toolchain. For C/C++, the mechanism is largely manual, and can be automated with scripts or with the build tool. For newer languages, tools like NPM will need to be hooked into the toolchain. The ease of library dependency management is one of the appealing aspects of newer languages, and making it easier for a developer to hook in libraries also makes it easier for DevOps tools to make use of library management functionality.
You. Rock.
Whatever your language of choice, in the end it will likely be your build tool that links it to DevOps. Maybe we should do a series on those, too; comparing when to use Gradle versus Ant, for example. Until then, keep rocking it. All development depends upon embedded in the end, so you’re holding up the foundation.
Continuous delivery (CD) and all the other continuous things—continuous integration (CI), continuous testing, continuous deployment—have become the new mantra of DevOps. CI/CD adoption typically starts with agile development teams working on new or well-funded systems. But what about the rest of the world and all of those “other” applications, under-funded IT teams are responsible for supporting? Can or should continuous delivery be a reality for all applications?
The answer is a resounding yes! No application is an island. Every application is subject to change, whether it be code changes, patches to the OS, changes to the supporting databases or changes to the infrastructure it is running on. Without a regulated pipeline to deliver changes quickly across all systems, organizations expose themselves to unforeseen risks and escalating maintenance costs.
No matter how new or well-funded an application is today, it will soon become one of many other applications that have to be secured, patched, updated and maintained as part of an organization’s IT estate. For example, consider all those “hot-new” Windows IIS sites built in the early 2000s now sitting on Windows Server 2008/R2, which reached end of life Jan. 14, 2020. Unsupported operating systems are not only costly but they also provide prime targets for cyberattacks, (the Bluekeep Vulnerability being just one of many examples).
The term “technical debt” was introduced in 1992 by Ward Cunningham to describe what happens when we fail to adequately maintain what he calls “immature” code:
“Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program un-masterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite … The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of anunconsolidated implementation.”
Organizations Must Navigate Complexity
The “J-Curve of Transformation” included in the “The State of DevOps, Dora Report” visualizes the challenges large, complex organizations face when automating delivery pipelines. Teams first target high-profile projects and quick wins and then see a drop-off as they’re faced with mounting complexity and technical debt.
Nowhere is complexity and technical debt more relevant than when it comes to mission-critical commercial-off-the-shelf (COTS) applications Microsoft SQL. Manual controls, layers of process and siloed support teams are all commonly associated with these types of apps. The term “bi-modal” IT is commonly used to describe the variance in delivery processes used for these types of apps versus custom apps being released as part of continuous delivery pipelines.
Not only are COTS apps handled in this “bi-modal” fashion, but they are also the “forgotten” and the “hidden” applications—the forgotten being legacy applications still in use but no longer being actively developed, and the hidden being all the applications needed by IT to run IT operations. To succeed at continuous delivery, organizations need to apply standardization across delivery pipelines for all teams and environments including complex, forgotten and hidden applications.
Complex: Mission-Critical COTS Applications
Large, mission-critical applications such as Microsoft SQL present unique challenges to teams focused on enterprise DevOps, but successful CD pipelines are possible. Teams must first recognize that packaged applications are fundamentally different than custom-built applications. Similar to older applications (which many packaged applications also are), the fundamental challenge is creating an automated way to build packages that can then be consumed by the pipeline. Success here also requires additional intelligence about the underpinning proprietary services and technologies supporting the packaged application.
Forgotten: Legacy Applications
There are myriad reasons why older applications present major challenges to organizations trying to achieve continuous delivery: technical debt, lack of resources, required refactoring, operating platform dependencies and a fear of business disruption, to name a few. Updating these apps many times requires individual acts of heroism, involving an abundance of manual efforts in which runbooks are individually updated, shadow sessions are invoked and the impact on dependent systems is typically not known until the update hits production.
Getting started with continuous delivery requires creating an automated build package that can then be deployed via the pipeline to the preferred destination—cloud, on-premises or hybrid. If the application and all of its dependencies have been successfully abstracted from the underlying operating system and infrastructure and packaged accordingly, it can be consumed into the pipeline and deployed anywhere without having to refactor or rewrite the application.
Hidden: IT ‘Owned’ Applications
The Digital Age has led to an exponential growth of applications used by the business (websites, distribution, POS, etc.) as well as third-party applications/tools used by IT teams to build, test, deploy, manage, secure and monitor those applications. In many cases, these applications have become just as mission-critical as the business applications they’re supporting, but they’re not typically treated as “applications” by the business.
In many cases, they remain completely hidden from the business, with little understanding of the value they provide. Often there is no clear owner for the application, different teams use the application in different ways, updates and patches are handled ad hoc, and expertise is limited to a few individuals within the organization (who take the knowledge about the application with them when they leave).
Ultimately, third-party applications used by IT need to be managed like any other application. If not, delays in release and production failures caused by changes not properly tested in pre-prod will happen.
A report published by Harness, a provider of continuous delivery (CD) platform accessed via the cloud, finds organizations are spending on average $109,0000 per year just to deploy per application.
Based on a survey of more than 100 organizations, the report finds organizations are struggling with deployment frequency, lead time and meantime to recover after a failed release.
On average, organizations are deploying code to production every four days, which takes about eight hours to complete, according to the report. An average of 11% of those deployments fail and those failures take an average of 60 minutes to manually roll back.
Steve Burton, CMO at Harness, said that while a lot of progress has been made in recent years in terms of implementing continuous integration (CI), the continuous delivery (CD) side of the DevOps equation remains challenging. Each platform an application gets deployed on is a unique “snowflake” that requires organizations to rely on custom scripts to deploy an application. The report finds deployment pipelines are expensive to create and maintain, requiring two to three dedicated full-time employees and up to 66 hours to onboard a new application. New artifacts on average took 5.5 hours to reach production and then 10 hours per deployment.
Harness has been making a case for a dedicated CD platform that is accessed as a software-as-a-service (SaaS) platform. That approach provides a way to automate application delivery in a way that more easily complements the variety of tools and platforms organizations rely on to build applications, he said.
The Harness report finds 71% of respondents employ the Jenkins CI/CD platform. Other popular tools and platforms include Jira project management software (76%), Selenium for testing (63%) and Amazon Web Services (AWS) for cloud deployment (65%). While Jenkins can be employed to deliver applications, Burton said the survey results make it clear there’s not been a lot of progress when it comes to CD.
It’s too early to say to what degree changing economic conditions brought on by the COVID-19 pandemic might encourage IT organizations to rethink their approach to DevOps. Organizations are undoubtedly going to be more sensitive to cost. Much of the cost involved in DevOps comes from first standing up and maintaining the DevOps environment and then hiring IT professionals with DevOps skills to manage it. A SaaS platform, in contrast, is maintained by the provider, comes with built-in analytics tools, enables automatic rollbacks and is paid for on a consumption basis, notes Burton.
No one knows for sure at what rate organizations might be rolling out new applications in the months ahead. While some may choose to pull back, others are advancing various digital business initiatives as part of an effort to become more resilient. In many cases, that means replacing many legacy applications with fewer modern applications that run natively in the cloud.
Regardless of the path forward, the one thing that is certain is the level of scrutiny being applied to DevOps efficiency is about to substantially increase.
At its annual SIGNAL conference, Twilio today launched an initiative intended to make it easier to embed a variety of communication services within an application in the context of a DevOps process.
Quinton Wall, senior director of developer marketing at Twilio, said the open source Twilio Command Line Interface (CLI) tool, now available in beta, will make it possible to incorporate Twilio cloud services within a larger DevOps toolchain.
Twilio provides developers will access to a range of SMS, audio and video services that can all be incorporated into applications via application programming interface (API) calls. The pipelines created using those APIs now can be stored and shared via GitHub.
The CLI tool also makes it possible to extend those services via Plugins, said Wall. In addition, DevOps teams can invoke an existing serverless computing capability from Twilio to invoke the company’s services using functions, added Wall.
It’s not clear to what degree cloud services such as Twilio will be invoked using serverless computing frameworks going forward. Many of the capabilities that developers once were required to embed in their applications are set to become external services that applications call when needed by launching a function. While that approach makes the application more efficient, it puts additional pressure on IT teams to manage all the calls to various serverless computing frameworks within the context of already complicated DevOps pipeline.
While serverless computing frameworks are still an emerging IT platform, the rate at which serverless computing frameworks are being adopted suggests the day when they are commonly included with a DevOps toolchain is not very far off.
In the meantime, Twilio is clearly hoping that by making its communications services easier to invoke within the context of a DevOps toolchain will increase consumption. Twilio has long exposed REST APIs, but the CLI tool will make it easier for organizations to standardize on Twilio communication services across a range of applications. By exposing those services via APIs and a CLI tool, Twilio is betting that the days when end users opened a separate application to communicate are numbered. Instead, most users will invoke communications services within the context of, for example, a business intelligence application that is already open. That approach also eliminates the need to invest in dedicated network hardware to run unified communications applications that, from an API perspective, are often more difficult to invoke programmatically.
As DevOps processes become more widespread, it will be interesting to see how many other providers of cloud services start to routinely make available CLI tools. Arguably, any provider of a cloud service that doesn’t make a CLI tool available will find themselves on the outside of a DevOps process looking in. Service providers that provide a CLI tool will be preferred among organizations that embrace best DevOps practices. In fact, the challenge DevOps teams soon may face is not whether there is a CLI tool available, but rather determining which of the many available best fits within the DevOps processes they have adopted.
As DevOps functionality continues to expand, we’re looking at a new vista for freedom of applications. Our apps can be moved around as we need them; we can build-test-deploy on the fly; and we have the ability to monitor whatever is needed. The price we pay is one we gladly take up: implementing new toolchains to drive the transition and getting those toolchains integrated into the entire development and operations process. Yes, we have an entire organizational side, too, but for this blog, we’ll talk about tools.
Why Tools?
Why are we going to discuss tools alone if this is about DevOps? Because it is a different set of problems to move from one organizational structure to another versus moving from one toolset to another. While DevOps is giving us independence from a lot of traditional infrastructure issues, the reality is that it is creating dependencies upon the very tools/toolchains we are using to gain that independence.
Confusing? Let’s try looking at it differently. The new vendor lock-in will be DevOps tools. While they are freeing us from vendor lock-in on several fronts, you are unlikely to make a quick move from, say, Ansible to Puppet or vice versa. It can be done, and some organizations even do a little of both to make sure their options are open. But most shops will pick one and run with it, because that creates a single training and maintenance direction.
Why Now?
I (and others) have alluded to this issue in the past, but it is of growing importance as vendors start to take what should be cross-portable tools and customize them to limit portability. Container management, for example, is available on every major cloud vendor these days, but using the vendor’s bundled container service is convenient and more difficult to move away from. That is but one example of many.
And the importance of these tools/toolchains is growing at the same time that their use is growing. Soon, in a DevOps-heavy shop they will be essential and locked-in as if they were cemented.
So, What Are You Saying?
Pick DevOps tools as if they will be there for decades. This is not how DevOps teams are encouraged to think, but you are building a DevOps infrastructure that, if adopted broadly in the organization, will be difficult to move away from to any significant degree. Just like these days you would need a driving reason to port thousands or hundreds of thousands of lines of code, DevOps scripts are growing and the number of DevOps scripts are multiplying. As you fold security, storage and networking into that environment, and build real-time reporting that you are going to rely on for years to come, make certain what you have is good, if not great. In many ways, DevOps thrives on “good enough” without thought to long-term futures, but the investment required to have a fully developed DevOps environment strongly implies that what an average enterprise is doing today will be what it is stuck with for a good long while. That’s not a place for “good enough” if you know there is better out there.
It’s Not All Unchangeable
Some bits of the environment can change over time, of course. Better data collation/integration technologies no doubt will take over for whatever you are using for reporting now, as well as AI-based solutions that can plow through the growing pile of machine-generated data to get a systemic view of what is happening. But for the most part, build it like you’ll be maintaining it for years to come, because much of the environment you will be.
The 2018-19 school year is in full swing, and just like the kids are going to the bus stop with their new backpacks and shoes, it’s time to refresh your DevOps tool chain and look to the future. Remember, just like education, DevOps never ends. It’s a lifetime pursuit that constantly improves your life.
The DevOps tool chain of the future must include:
Trunk Releases
Time to get your branch and merge skills down pat. Git is the best source code control to offer this to development teams. Companies should be actively moving to git to allow their development teams isolated feature development with pull merges and pushes to the trunk for releases.
If you are not using git, it’s time to start justifying why you are not. Given the speed at which businesses are moving, it is time eliminate blockers for development to release features. Git is built for speed and large numbers of dispersed developers. Remember: it was built by Linus Torvalds to support Linux kernel development.
Database Development Tools
When planning for your DevOps tools, seriously consider database development tools as well. But, if you want comprehensive results when developing your database, you need tools with a DevOps flare.
If we didn’t have the efficiency and speed that we got from Agile software development, we wouldn’t have created DevOps. So, bringing Agile to database development was a must for database DevOps to solve problems. One tool in particular that we use supports some incredible features for Agile development. A database is different than an application; because of this, a database will have state. So, having a database instance we can compare to with our team is critical. The tool we use has this functionality, which has allowed us to thrive. It also lets users work with existing source code control along with a live database to help database developers. Because of this, users can execute this functionality against database objects such as stored procedures and tables.
Application Release Automation
Application software can be difficult to manage. Often, they have too many components to manage easily, which is where automation can help. Application release automation helps your team move from learned and taught processes to basic scripts that are easily scalable and can help deploy applications rapidly. If you’re working with a team that cares about data and DevOps, Application release automation is a critical tool.
Test Data Management
No matter how rapidly you are able to deploy applications, you’ll need to test. The faster you deploy, the more tests you will need to run. But a massive problem with testing can be the lack of quality. Many applications pivot functionality depending on the data stored in a datbase. So, providing data that is or, at least, matches the production data is critical to guarantee high test quality. Without the right data, you could be running massive amounts of tests that are also providing bad/false results. And, with DevOps, you’re committed to improving your software and working to enable more testing for that software.
Don’t Forget the Database
A key finding of the “2018 State of DevOps Report” is that integrating database change management into your DevOps toolchain early in the process drives higher performance.
This is obvious to anyone that has released software before. However, for large siloed enterprises, this is non-obvious. For too long, we have been told to leave the database to the DBAs. Well, it turns out that approach (though sensible in the ’90s, when we started it) is no longer working for us.
Your application will not run without database schema and logic changes about 80 percent of the time. So, there is no reason to have a separate manual process. Here’s someone saying that exact same thing in 2017: https://www.youtube.com/watch?v=DDZIiGT3jzs
Now What?
Having all the right tools is a necessary first step, but it doesn’t stop there. To fully succeed with these tools, a few key strategies must be put in place as well:
One Ring to Rule Them All
DevOps has taught us to break down silos. Yet, we see silos now being created based on tool choices. Companies should standardize DevOps tools across the entire value chain. If some parts—say Dev and Test—are using Artifactory, for example, the operations team should also use it and not rely on the release teams to put the release on a shared network drive. Ops should use Artifactory, too.
This will require some horse-trading. Some teams will dig their heels in on a tool because it provides value specifically to them. Well, so be it. As one of my favorite Venture Bros. character, Dr. Henry Kissinger, says, “Compromise, my friend, is the essence of diplomacy, and diplomacy is the cornerstone of love.”
Cloud First
When I hear “cloud” from IT leaders, I immediately think of Inigo Montoya from “The Princess Bride” when he said, “You keep using that word. I do not think it means what you think it means.”
The National Institute of Standards and Technology has defined cloud computing to have five essential characteristics:
On-demand self-service
Broad network access
Resource pooling
Rapid elasticity or expansion
Measured service
Your DevOps tools should also have these characteristics. Specifically, if you are not allowing external teams to utilize your tools and require someone to make a request via ticket first, you are doing it wrong.
Time to learn how to offer DevOps as on-demand self-service.
Ongoing industry disruptions are forcing businesses to change their operational model; that’s the only way to avoid and survive digital bankruptcies.
In North America, Sears Canada filed for bankruptcy, while Toys R Us and Weight Watchers were on the verge of it. In Europe, particularly, in France, banks including Societe Generale and leading retailers including Carrefour are anticipating it through ambitious and innovative digital transformation programs.
The cheap access to innovative technologies enabled by cloud services providers including Amazon Web Services (AWS) has caused a proliferation of innovative tech startups and technology companies, making competition tougher for established businesses.
The innovative digital products and services they deliver are slowly but surely substituting conventional ones. As an example, Weight Watchers’ weight-loss programs did not resist innovative wearable devices, such as the Fitbit Tracker, that helped millions around the world lose weight. Trackers measure data such as the number of steps walked, heart rate, quality of sleep, steps climbed and many other personal metrics involved in people’s health.
Digital products and services are becoming customer consumption standards, accelerarated innovation life cycles are now the competitive advantage to have and DevOps in its entirety is the capability companies must equip themselves with to make substantial digital profits.
In 1985, Harvard’s Strategy professor Michael Porter unveiled to the business world in his best-selling book, “Competitive Advantage,” the concept of value chain. It ‘s been revolutionizing business practices for more than 30 years, and inspired approaches as varied as Michael Hammer’s Process Reengineering, Toyota’s Lean Production, Total Quality Management (TQM) and even Software Capability Maturity Model (CMM).
The value chain’s principle is the notion that in every single company there’s a subset of interactions, staff and skills, processes and practices and tools and infrastructure that repeatedly generates expected benefits. That subset is what’s meant by the value chain; to succeed, businesses must continuously optimize it.
Today, software development is the foundation of digital products and services; it’s becoming the fundamental industrial activity. By providing the technological, organizational, and operational framework that will enable digital profits, DevOps is replacing the value chain as Porter designed it. It’s the competitive instrument businesses need to make big gains.
Michael Porter’s Value Chain: Purpose, Foundations and Principles
The value chain, through focusing companies on their added-value activities and resources, has been revolutionizing businesses’ ability to compete for 30+ years and made several thousands business leaders successful around the globe.
Figure 1 – The Original Porter’s Value Chain
What you must know is, the underneath principle is, only a subset of the company’s activities—Primary activities and Support activities—can repeatedly generate expected benefits. That subset is what’s meant by value chain.
Let’s discuss them!
Creating Value: The Primary Activities
The objective of the primary activities is to create value. They include seven activity groups:
Inbound Logistics
Operations
Outbound Logistics
Marketing and and Sales
Services
Inbound Logistics performs supply chain functions. It’s a group of key supply chain processes and associated experts, tools and infrastructure. The mission is to make sure the company gets on time the best material to manufacture top products and services.
Operations refers to manufacturing functions. It puts together the company’s top experts, engineers and product managers to design, develop and test products and services. They take advantage of key processes and industry best practices to make the company’s products and services as innovative and profitable as possible.
Outbound Logistics performs distributions functions. It’s a subset of the company’s top distribution partner relationships management (PRM) experts mobilized across the company using top distribution processes, practices and tools to make sure the company’s productions and services are properly distributed across its partner networks and make a profit.
Marketing and Sales, as the names suggest, perform marketing and sales activities. It is a group of the company’s top marketers and salespersons mobilized through top marketing and sales processes and practices to make sure the business make profits.
Services refers to post sales activities. It’s a group of the company’s best customer relationships management (CRM) experts and associated top processes, practices and tools mobilized to make sure customers have the best experience with the company’s productions and services.
Making Value Creation Sustainable: Support Activities
The primary activities do not generate value on their own; they need levers. Their purpose is to be the value chain’s support activities, making sure the company generates sustainable value. They include four activity groups:
Firm Infrastructure
Human Resources
Technology Development
Procurement
Let’s how they enable value creation activities!
Firm Infrastructure is a group of high-level executive experts appointed to guarantee the company’s infrastructure profitability. Such executive experts include chief information officers (CIOs), chief technology officers (CTOs) and chief enterprise architects (CEAs), and they rely on top processes, practices and tools such as ITIL, IT Services Capability Maturity Model (CMM) and TOGAF to guarantee the company’s infrastructure profitability.
Human Resources is a group of the company’s selected recruiting and human resource management experts and the associated top processes, practices and tools. Its mission is to not only make sure the company has the top experts it needs, but also get from them their maximum contribution.
Technology Development relates to research and development (R & D) activities. It’s an elite of experts dedicated to monitoring markets trends and developing product ad service prototypes likely to create value for the company. They rely on extremely sophisticated product and service engineering processes, practices and infrastructure.
Procurement relates to a selected group of the company’s investment decision experts. Relying on top financial processes, practices and tools, this group’s mission is to guarantee the maximum return on the company’s investments.
Why DevOps is the New Value Chain
Contrary to what many thought leaders, experts and solution vendors pretend, DevOps is unknown; it can’t be narrowed to the complex toolchains IT vendors have been selling to CIOs. Things aren’t that simplistic.
DevOps According to Chef’s Adam Jacob’s Perspective
Adam Jacob, co-founder and CTO of Chef, wrote a memorable, article about DevOps: “The Secret of DevOps: It’s Always Been About People, Not Technology.” Relying on his experience working with the inventors of DevOps—Jesse Robins, John Allspaw, Paul Hammond—he provides an unprecedented and accurate perspective of DevOps.
He reminds this, “Becoming better at building and delivering software is the stake. It’s not an optional piece of their strategy: It’s the future of how their customers want to work with them. Software is table stakes for survival.”
He adds, “But the real answer lies in looking at what John, Paul, and Jesse were doing in 2009—not in the specific technical choices they made, but the style in which they worked, the essence of what they believed made them high functioning and successful. … Then the challenge begins: how to apply this new style to businesses trying to become better at building and delivering software.”
He proceeds, “DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible towards their goals. Tools matter. Make no mistake, trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure.”
Then concludes, “Fundamentally DevOps is about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.”
DevOps’ Fundamental Building Blocks
What’s interesting in Adam’s rhetoric is, two groups of key words and sentences help to bring out two fundamental components of DevOps.
People, customers, work, work style, beliefs, bringing together people, empowering people are part of the first group. It relates to what experienced and qualified business transformation experts refers to as operational model.
Technology and tools—and make no mistake, tools matter—don’t the change the way you work without changing the mechanic underneath are all part of the second group. It relates to what experienced and qualified business transformation experts refer to as a technology platform, known by DevOps experts as continuous delivery (CD) platform.
The following picture is a DevOps model derived from Adam’s perspective. It makes easy its understanding:
Figure 2 – DevOps as the New Enterprise Value Chain
As illustrated, DevOps can be modeled as two-components business capability including:
The operational model
The CD platform referred to in this article as DevOps automation toolchain
Let’s see how these two components are making DevOps, the powerful business capability CIOs have been expecting!
The DevOps Automation Toolchain
The automation toolchain or CD platform is what many either refers to as or confuse with DevOps. It conceptually structures software deployment in four steps:
Source
Build
Test
Deploy
Each stages uses one or more products as illustrated in the following table:
Figure 3 – Automation Toolchain Features
The Agile and Lean Operational Model
The operational model is the poor relation of DevOps; it’s totally either unknown or ignored by 98 percent of business leaders and their CIO. It’s where agility, flexibility, responsiveness and even innovation culture are implemented. It organizes the application development effort in a four-step circular life cycle:
Plan & Measure
Develop & Test
Release & Deploy
Monitor & Improve
Each stage mobilizes specific staff and skills, uses specific processes and practices, tools and infrastructure and, more importantly, specific Agile and Lean practices. The following table summarizes each stage:
Figure 4 – DevOps Agile and Lean Operational Model Features
Why DevOps is The New Enterprise Value Chain
One of the problems with the value chain as Michael Porter thought it is, it has a compartmental vision of the business with two categories of activity divided each in several processes and associated staff, skills and tools.
This perspective nurtures organizational silos and prevent cross-functional collaboration. It slows down problem-solving and decision-making and inhibits innovation culture.
The value chain as Michael Porter thought it didn’t help Sears Canada to avoid digital bankruptcy, it didn’t prevent Toys R Us and Weight Watchers get on the verge of it.
Where DevOps brings value and fills the gaps of today’s value chain is, it not only provides a business capability that’s easy to deploy but also an organizational, operational and technological framework embedding the Agile and Lean practices, as well as the automation toolchains companies need to survive their industry disruptions and make substantial digital profits.
Key Takeaways
Industry disruptions are a reality and properly transform the business is the only solution. Sears Canada, Weight Watchers and recently Toys R Us learned it the hard way.
In 2018 make DevOps transformation your priority investment decision, I’m not talking about DevOps’ automation toolchain but DevOps a business capability which includes the Agile and Lean operational model and the automation toolchain.
Automation and continuous delivery are shifting from being industry trends to becoming industry standards for fast and effective app deployment. To compete in today’s market, organizations must adopt technologies and applications for more rapid deployment. But with so many tools available, this is incredibly challenging without knowing which specific tools and methodologies are most effective.
Automic, now part of CA Technologies BU, has been a leader in this space and just launched the “Continuous Delivery Map,” inspired by the London Tube. Designed to be interactive and instructive, this subway-like map helps customers easily visualize and assess the best use cases for continuous delivery tools for their own digital transformation and reduce the confusion for IT professionals.
Before I get into the specifics though, I wanted to share a few trends I’ve been following that have ultimately led to development of this map. In recent years, we’ve seen an expansion of freeware and open-source offerings for automated tasks within IT. But organizations must consider and address the long-term sustainability of these software products since the cost of adoption could be risky. It may only be useful for two to three years, until community developers move onto the next new thing—leaving orgs with the costly task of rewriting delivery pipelines or automation mechanics every three to five years. This is compounded by the fact that the term “DevOps’ itself has even become a trend”—it’s catchy and grabs attention, so everyone is branding themselves as a DevOps tool, even if it’s not a core use case of a tool. Now, there is increased confusion on what tools are available, what aspect of DevOps they’re most valuable for, how sustainable they are, and what the market thinks about them.
Over the past few years, I’ve also seen some organizational shifts as well. Starting at the top, I have noticed that CEOs have recognized the competitive advantages of applying DevOps practices, including faster software production, greater revenue gains and better responses to market conditions. Leadership teams are now responding with mandates for DevOps implementations in their own orgs, and C-level hiring and firing decisions are being influenced by their awareness of DevOps. Separately but related, development and operations teams have continued to fundamentally work and solve problems differently, with developers working in a linear fashion, solving problems sequentially and operations working in a circular fashion with frequent interruptions. Automation is the key to making operations agile because it will reduce interrupt-driven processes and practices. An agile operations team will empower true DevOps because Ops members will have time to collaborate and contribute to DevOps practices. Without it DevOps really means DevNoOps.
Enter the Continuous Delivery Map
We developed the Continuous Delivery Map to help our customers and the industry at large understand the hundreds of available DevOps tools across several “lines.” We sought to create a centralized, unbiased way for IT professionals’ research and visualize how DevOps fits into customers’ continuous delivery pipelines. After thinking more about patterns that fit a delivery pipeline, we settled on a metro rail system similar to the London Tube or New York Subway. Now, with this map, customers can easily visualize the ‘tooling’ in their continuous delivery process with an understanding of the tools best use cases. You’ll see we have several “lines” from middleware to continuous integration to toolchain orchestration—all with more information on each product in each line.
As the tool evolves, we hope the map will become a platform that uses data and feedback to rank the tools, capturing a market consensus on best-in-class DevOps tools. Customers will then be able to truly see and choose the best tools in various categories that meet specific continuous delivery needs and strategies.
“What’s in a name?” wrote the greatest Bard who ever lived.
All I can say is, he lived in simpler times, when DevOps and the confusing world of continuous integration (CI), continuous deployment (CD), CI/CD, the other CD, application release automation (ARA), pipelines, assembly lines, etc., didn’t exist.
The biggest challenge today is that vendors use overloaded terms to describe completely different use cases. CI vendors claim to support CI/CD, even though the “D” here is just a deployment to a development environment and not staging or production. ARA vendors claim to enable continuous delivery, even though they do not include critical steps such as infrastructure provisioning, security patches or configuration management.
The terms “pipelines” and “assembly lines” are relatively new. Multiple vendors have recently announced pipelines and assembly lines, and the differences aren’t obvious at first glance. So let’s do a deep dive.
What are CI Pipelines?
Continuous integration has evolved tremendously over the last few years. What started as a simple process of automating build and unit tests for each code change has evolved into a pretty complex workflow.
As an example, look at the different CI workflows shown below:
In classic CI, all build and test instructions were included in a single blob and instructions were executed serially. If all instructions executed successfully, CI was successful, and if anything failed, then it was marked failed. Almost all CI providers, until recently, offered just classic CI.
However, as CI became mainstream, developers wanted to define more complex workflows with decision trees and parallelism. CI pipelines support this complexity, such as:
Defining the CI workflow in stages, so you can get results from a stage faster without having to wait for the entire workflow to finish. This also enables scenarios such as running a basic test group and only running the extended test suite if the basic tests pass.
Running stages in parallel, so you can split tests or test your code against different environments or language versions, and get faster feedback.
Forking your CI logic based on the results of a stage.
While CI pipelines are a huge improvement over classic CI, they are still limited to developer-focused workflows. Jenkins, Teamcity, Shippable, Gitlab and CircleCI all support some form of CI pipelines.
What are DevOps Assembly Lines?
DevOps assembly lines are focused on automating and connecting activities performed by several teams, such as CI for devs, infrastructure provisioning and configuration management for ops, test automation for test, security patching for SecOps, semantic versioning and approval gates for release managers, deployments for multiple environments, and so on.
Today, most organizations use various tools for automating specific DevOps activities. However, the DevOps toolchain is fragmented and gluing it together to achieve continuous delivery is a challenging task.
Most teams adopt one of the following approaches:
Using cultural collaboration as the glue between silos. As an example, when a new application version is available, the test team creates a JIRA ticket and assigns to ops. Ops then copies the application version information into their deployment scripts and run them.
Writing ad-hoc scripts to trigger one activity from another, including passing state information through intermediate storage such as S3. In this case, the DevOps engineer would likely write a Jenkins job that runs automated tests, and then pushes application version information to S3. Another Jenkins job polls the S3 bucket, and when a change is detected, runs the deployment scripts.
The first approach introduces inefficiency and unnecessary human-dependent steps. The second approach is better, but only works well for small teams working on a single application. It creates a Frankenstein of spaghetti automation when you have many applications or even a single application with microservices.
DevOps assembly lines address this problem by focusing on gluing together these various DevOps activities into streamlined, event-driven workflows with the ability to easily share state and other information across activities.
The following image shows a typical assembly line for a single application or service:
See the difference? The CI pipeline is just ONE activity in the assembly line. Each of the boxes in the picture above is a pipeline, just for different activities! Each has specific needs with respect to tools integration, runtime, configuration, notifications, etc. In addition, each pipeline is owned by a different team, yet needs to interact with other pipelines and exchange information. For example, if the ops team changes provisioning scripts for staging environment, the test team needs to redeploy the application and run performance tests.
A DevOps assembly line is, therefore, a “pipeline of pipelines.”
DevOps assembly lines need to support the following:
Ability to easily define workflows across multiple pipelines.
Versioned and reusable workflows, enabling rapid changes and scaling for multiple applications and/or microservices.
Integrations with all popular source control systems, clouds, artifact repositories, DevOps tools, languages, services, etc.
Runtime to execute every pipeline, including pre-installed tools and CLIs, and the ability to use the right runtime, depending on pipeline type.
Accelerators/playbooks for common pipelines and tools.
Ability to pass state and other information while triggering dependent pipelines.
Automatic triggers or manual approval gates between each pipeline.
Configurable notifications for each stage of every pipeline.
Release automation features such as semantic versioning of packages.
Audit trails for each pipeline, with the ability to go back or forward to a specific state.
Abstraction of all sensitive information like passwords, tokens, keys, etc. for security reasons.
Roles and permissions restricting assembly line and pipeline actions.
Manage DevOps infrastructure, including spinning VMs and containers up and down as required.
Visibility into each pipeline and stage, including logs, status and versioned data.
Metrics and Analytics across pipelines to help identify bottlenecks.
In short, DevOps assembly lines help automate and scale end-to-end workflows across all teams and tools, enabling continuous delivery.
About the Author / Manisha Sahasrabudh
Manisha Sahasrabudhe is co-founder and vice president of product management at Shippable. Prior to Shippable, Sahasrabudhe was senior program manager at Microsoft. She can be found online at Linkedin.
Manisha Sahasrabudhe is co-founder and vice president of product management at