May 31, 2018 by Armory
So you’re thinking about moving to the cloud, and containers, or perhaps you’re already on the path to move from monolith to microservices, or to migrate from VMs to containers. Congratulations, and welcome to the future.
This change is more than just changing platforms. Moving from waterfall or even agile to the complicated world of cloud, containers, microservices and continuous integration/continuous delivery (CI/CD) requires not just a change in technology, but in how you think about how your company works. The broader exposure, more reach, and increased speed comes with the need for non-technical changes in the structure, thinking, and organization of your company as well.
At Armory, we don’t just throw you into the deep end; we work with you to position your company for success. Here’s what we see progressive engineering leaders doing to bring that into their companies:
Regardless of your product, once you move into the fast-paced world of cloud-based architecture, your company will essentially be a software company. We’re used to thinking of software companies as those that deliver technology like Google, Microsoft, and Oracle. IT has moved from an afterthought into being an integral part of the business model, not just a place where data resides. Also, using continuous integration/continuous delivery (CI/CD) means that a large part of your offering is your ability to deliver software along with your product. So Tesla is a software company, as is eBay, as are you.
Nicole Fosgren, Jez Humble, and Gene Kim talk about this in their new book Accelerate. In the world of CI/CD, your ability to deploy better software faster becomes your competitive edge.
This change to cloud and CI/CD requires an energetic frame of mind. With a monolithic architecture delivering software using the waterfall method and once-a-year release cycles there was much time to plan and make changes. Not anymore.
Today’s pace of innovation requires delivery of new services, product updates, and patches multiple times each week, or each day, or even each hour. In addition, there is no more shutting the system down for several hours to install updates. With CI/CD, deliveries happen with production up and running. Armory’s platform, built on the open-source software delivery pipeline Spinnaker, helps automate and streamline this process.
The move to the making your company a software-centric company is critical because your competition is not slowing down. Customers are expecting better quality service and 24/7 uptime.
The expectation is to keep up or kick the bucket.
With continuous integration/continuous delivery comes the requirement to test microservices in production, and with this comes the need to shift how your company deals with failure. In the waterfall or Agile development method, the goal is 100% perfection, and failure is seen as a punishable offense, either implicitly or explicitly.
With continuous delivery and distributed systems, the sheer complexity means that it is impossible to account for all possible contingencies before going live. You are still doing the standard sets of tests, but the final test is in production. Delivering software several times a week, or a day, in a technology stack where containers are spun up for a few minutes to perform a specific task then melt away mean that the final testing happens in production and there is no way to cover all contingencies. In such an environment, failure is inevitable.
"Failure should be treated as a learning opportunity," said Fosgren. Wait, what? She goes on to explain, "Since failure is inevitable, your culture needs to accept and accommodate that."
“Instead of asking ‘whose fault is it?’ ask instead ‘what can we learn from this? What information/process was missing that led to the failure? How can we get the team members what they need to make this not happen again?’ If you’re seeing a system failure and looking for whom to blame, your thinking needs an upgrade.’”
"A companion to dealing with failure is you deal with novelties," Fosgren said. With continuous delivery, new ideas are the lifeblood of system maintenance. "In your company, are novelties crushed, or are they implemented?" asked Fosgren. The answer to that question, they found, is dependent on the strength of your teams.
With the distributed technology of cloud and microservices comes the need to shift your company culture from top-down decision making to one where decisions can be made closer to the source of the problem, allowing changes in a few minutes instead of having to go up a chain of command. Jennifer Tejada, CEO at PagerDuty, said, "Without this change, she just becomes the Chief Obstacle Officer." So distributed organization should come along with the distributed technology.
Jez Humble, on his site https://continuousdelivery.com/ writes:
“Peer-reviewed research has shown continuous delivery makes releases less painful and reduces team burnout. Furthermore, when we release more frequently, software delivery teams can engage more actively with users, learn which ideas work and which don’t, and see first-hand the outcomes of the work they have done. By removing the low-value painful activities associated with software delivery, we can focus on what we care about most—continuously delighting our users.”
"Culture is transformative," explained Nicole Fosgren in a recent podcast. “We measure this in our work and we show that culture has a predictive effect on organizational outcomes and technological capabilities.”
Google has done much research, both internally and externally, on what makes the greatest team. The #1 ingredient was psychological safety leads to comfort with taking risks.
Their best advice for culture change: create teams where it’s safe to go wrong and make mistakes.
None of this happens without great leadership. Which most likely means your management teams will need some training. What makes a leader transformational? What traits should you be looking for?
According to the research in Accelerate, five characteristics are predictive of driving change.
Vision: Management keeps the big picture in mind.
Intellectual stimulation: Management is always learning and encourages their teams to learn as well
Inspirational communication: Management shares as much information as they can with their teams in ways their teams can consume and across multiple channels (Slack, email, message boards, meetings, etc). While all companies have information only appropriate to upper management, a distributed environment makes as much information as possible available to all levels of developers.
Supportive leadership: Management finds the lessons, and stays away from reasons punish
Personal recognition: Management recognizes good work and gives credit where it is due, publicly and often.
The good news is that these characteristics do not appear magically. Your managers and supervisors can be taught to apply these skills. Fosgren’s recommendation: invest in the tech, but also invest in innovative leadership.
The additional complexity also creates the need for an expanded definition of security.
With distributed systems, data can pass through dozens, or even hundreds, of APIs, each of which becomes a point of a potential security breach. So new questions need to be asked. What are the access control policies? Who can get access to which pieces of the stack? Is my data encrypted at rest? Is it encrypted while in motion? Most importantly, what is the process for applying patches promptly?
Keeping up with patches is critical because 90 – 95% of breaches exploited identified system vulnerabilities when a patch was available, but not applied. The announcement of a patch also alerts would-be hackers to the existence of the vulnerability. Unfortunately, this happened at Equifax in 2017. The patch was available, but not applied.
Even though most cloud providers include security in their services, backed up by an army of cybersecurity experts, it’s important for you to understand the expanded security needs of a distributed system so you can ensure the vendor has the knowledge, procedure, and policies in place. For any services controlled in-house, it’s essential that the company provides clear procedures for a secure environment.
While moving to the cloud, containers and a continuous integration/continuous delivery software development systems require a change of mindset and an increased pace of innovation, the competitive advantage, and other benefits make the change worthwhile.
Software deployment processes differ across organizations, teams, and applications. The most basic, and perhaps the riskiest, is the “big bang deployment.” This strategy updates all nodes within the target environment simultaneously with the new software version. This deployment strategy causes many issues, including potential downtime or other issues while the update is in progress. It […]
Read more →
Multi-target deployments can feel tedious as you deploy the same code over and over to multiple clouds and environments — and none of them in the same way. With an automatic multi-target deployment tool, on the other hand, you do the work once and deliver your code everywhere it needs to be. Armory provides an […]
Read more →
KubeCon+CloudNativeCon EU is one of the world’s largest tech conferences. Here, users, developers, and companies who have and intend to adopt the Cloud Native standard of running applications with Kubernetes in their organizations come together for 5 days. From May 16-20, 2022, tech enthusiasts will congregate both virtually and in person in Valencia, Spain to […]
Read more →