We discuss “The DevOps Handbook”, which was started over five and a half years ago and released in October 2016. Gene co-wrote the book with Jez Humble, Patrick Debois, and John Willis. The book includes over 48 case studies that range from unicorns like Google, Amazon, Facebook, but also horses like Nordstrom, Target, and Capital One. Many of the case studies came from the DevOps Enterprise Summit. The book has discussions of both greenfield and brownfield deployments, even touching on mainframes.
The most common question enterprises ask about DevOps is: Where do we start? “The DevOps Handbook” starts with a chapter on starting with DevOps by picking the right value stream. The research started by looking at where successful unicorns and horses started with their DevOps initiatives.
They also look at the failed DevOps initiatives to learn what to avoid. Failures can be categorized in two ways: starting too small or starting too big. Initiatives that start too small often start with a simple Chef or Puppet project end up looking like like more of a hobby. When they finish the project, they haven’t actually proven anything and the project gets easily dismissed. Initiatives that start too large often choose something too critical to the operations of the organization, and is unforgiving of mistakes. The most successful journeys start with something that creates a material contribution to the organization, but is small enough that it does not get shut down early for small mistakes. Their studies found that one out of three leaders who were starting these transformations were being promoted for their contributions.
There is no one answer for how to change an organization’s culture for DevOps, but there is a prescriptive set of guidelines. The technical practices do not change such as version control, continuous testing, continuous integration, automated deployments, proactive monitoring of the production environment, security integrated into every step. What is different is where these initiatives start from. Some come from the Director ofr Operations, a Chief Architect, or even Director of Development. This transformation starts from different people and teams at different organizations. There are many different ways to reach a great DevOps practice.
The three guiding principles of DevOps are:
There is a myth that with DevOps you can’t have any central control. We discuss differences in self-service teams like Netflix and Amazon to function-based teams used at Google and Disney. We look at Etsy’s liason model assigning ops engineers to various service and product teams.
Many companies do well with the technical aspects of DevOps, but struggle with the culture changes it requires. Ten years from now, it will be about creating learning organizations and the command and control model will not be effective. It won’t be about who caused a problem or who to blame, but will be about creating a culture of learning for a successful team.
We discuss serverless computing and what it means for enterprises. We compare different serverless computing platforms, look at pricing models, and discuss how to determine which applications are right for serverless computing.
Serverless computing is a manifestation of the idea that we should focus on our applications and focus on the code that makes them efficient in providing high-levels of functionality. It brings enterprises away from care, feeding, and operations that are low-calorie work. At this point all major cloud vendors have announced some implementation of serverless computing that allows developers to take a section of code, deploy it on their platform, and have it execute for either very short periods of time, or very long periods of time. In a way, developers do not need to worry about operating systems, connectivity, installing patches, upgrades, or any of the operational pieces that go with having a virtual machine or a physical server.
Serverless computing seems like something that should have been built into cloud computing from the beginning. With IaaS, we try to mimic what’s in the data center. They require most of the same upkeep as a regular server. Serverless computing abstracts us from having to deal with these details and allows us to deal with the brilliance of development instead.
It’s likely that if serverless computing had emerged in 2006, it would not have had an easy time being adopted. In early days of cloud computing, enterprises were trying to break data center habits they had built such as change management, control, and approvals that took a long time. Early services on cloud were focused on getting out of the data center, and allowed people to start the transition. If we had serverless technology at that time, it’s possible people would not have used it because it was too big of a leap to transition their enterprises and skill sets all at once. We’re at the time now where people have adopted the cloud and are comfortable with the concept of not having physical access to the applications and systems. We are now okay with not being able to touch the servers. Now people are realizing the amount of time that goes into patching systems and monitoring systems and that it is low-calorie work and doesn’t contribute to being able to build features and capabilities. We’re at that point in the adoption curve where people have adopted the cloud and shed those data center habits, and now they want to shed those operating system and server habits to make their operations more efficient. This is where serverless computing comes in.
To be clear, the servers are still there, we are just abstracting ourselves from having to deal with the operations and details. This allows us to focus on building the best apps we can without needing to worry about underlying infrastructures.
Security in serverless computing takes a certain level of engagement with the platform vendor to fully understand. Older models of building in network layers of protection don’t apply as much in the serverless world. With serverless computing, we look at the cloud platform (Azure, Google, AWS) to provide network-level security. It shifts the responsibility to enterprises to focus deeper on application-level security (log monitoring, databases, data stores) and to look for anomalous behaviors at the application-level.
In terms of what applications are best for serverless computing, consider it for net new based systems. Traditional lift-and-shift environments would typically go to virtual CPUs and storage devices that sit on the cloud. There are a variety of interesting startups looking at ways to automatically refactor code to move it from an OS-based environment to a serverless-based environment. As applications and companies continue to migrate to the cloud at an accelerated rate, we will see more of these migration tools to make the transition more simple and enable adopters of the cloud to use more innovative services rather than moving applications as they are.
We look at the tradeoffs between Amazon Lambda and Azure Functions.
In addition, Google is just beginning to play in the serverless computing space with its alpha version of Google Cloud Functions.
It’s important for enterprises not to do too many transformations at the same time. Take steps one at a time that are comfortable for the organization. First, move applications relatively intact to cloud for the ability to deploy infrastructures quickly and get elasticity and a better pricing model. Then, iterate by moving to a serverless environment to improve operations dramatically. This allows the organization to keep up with the technology changes as it matures.
We discuss Juniper Networks and their acquisition of Contrail, Oracle’s vendor lock-in and new pricing changes, and why Kubernetes has pulled ahead of Docker in the container world. Juniper Networks is expanding their cloud capability with two recent acquisitions: Contrail and AppFormix, a software-defined networking play and a cloud monitoring software.
For Randy, containers are the most exciting part of cloud computing right now. The Openstack movement is slowing down and there is fatigue because people are starting to realize that public cloud is going to win. Private infrastructures that still do exist (such as VMWare) come with too much complexity from set-up to organizing and managing. People are deciding to leapfrog past those now and going straight to containers. They want to pair containers with things like Contrail because the combination allows for a robust infrastructure that can run on both private and public cloud. An example of this is a recent Riot Games blogpost about streaming video games and shows how they combine container orchestration systems with Contrail to give themselves a true hybrid cloud solution at the container level. This means developers do not need to worry about what infrastructure they are running on.
In the news recently, Oracle doubled their license fees to run in AWS. As enterprises are migrating to the cloud, they have a lot of Oracle software currently running in their enterprise and are looking to bring licenses and run Oracle in the cloud, so now they’re being asked to pay more for that migration. This could lead to acceleration of companies leaving Oracle because of the higher prices. People are fed up with proprietary software, licensing, and vendor lock-in. Ten years ago, there weren’t a lot of alternatives to Oracle for relational databases. Now there are lots from Aurora, and RDS and Redshift on Amazon. The problem is, a typical enterprise built a lot of procedures and triggers in the applications that run in the Oracle database ten years ago. Now they either have to ditch all of that or rewrite it, which can be risky, or they can pay more for Oracle licenses and stay with it.
Oracle does not have a good cloud play yet, though they are trying. They do still need to upkeep the legacy databases for enterprises now as the transition occurs. Perhaps if oracle could remain reasonable on pricing, they would have more of a chance of surviving, but it seems the recent news makes it easier for customers to decide to leave. They may need to start skating further ahead of the puck soon if they want to weather the cloud disruption.
We also discuss Docker and why Kubernetes has taken the lead for container software in recent years. Docker took off because it was the “Easy Button” for application developers who did not want to learn Chef or Puppet. Then they tried to each Infrastructure teams who did not know what containers were, so they tried to add complexity to make containers look like nextgen virtual machines. That is not how app developers viewed them, and now Kubernetes has become more preferred. Most Openstack startups have bet on Kubernetes. Docker has built a big platform that has not found its killer app yet and are no longer able to take advantage over the dominance they once had. Docker acquired a lot of companies and linked together a lot of different technologies along the way, always adding layers of complexity. Kubernetes is in front because it has simplified everything and that is what developers want right now.
For an enterprise who is moving to Docker, Randy provides tips and warnings.
It won’t be easy, and be wary of anyone who tells you all the problems with containers are completely solved. Use DevOps and have an application-centric model, so you can focus on velocity.
We discuss how Fast Forward Labs applies the machine learning algorithms of academia to the business world to impact industries. They help clients leverage what they’ve uncovered in their research to build prototypes and demonstrate the potential of new algorithms. Companies are starting to use neural networks for things like image classification, natural language, text summarization, and more. Though it is not a new technique, it is new to the business world and is now available for companies to use. One example of a neural network use-case is to take a long article and automatically cut it down to the five sentences that capture the article’s essence. Artificial Intelligence has been around for more than 30 years, but what has changed now is that it is much easier to store data, and deep learning requires a large amount of data to be effective. Also, the cloud infrastructure makes machine learning possible today because it opens up the use of these algorithms to large companies and even small startups. AI used to require more horsepower, physical space, and cost more to implement than it does today.
Fast Forward Lab clients often struggle to identify the right problem for machine learning. For example, there is a lot of hype around conversational agents, or chat bots, today to replace human agents with AI. But early entrants have found that these bots do not get used frequently by customers, which turns out ot be a user experience problem and not something that can be fixed with machine learning.
The real promise of machine learning is that it can help us with repetitive tasks inside the company. Look in your organization for places where a similar decision or action needs to be made over and over and that is where machine learning could be used.
We discuss the different options for tapping into machine learning algorithms from AWS to Google TensorFlow and open-source tools to combine with them. The most important thing to get started is to determine what clients want to start with defining what the business is trying to achieve. Next it’s important to determine exactly what data is available, and only then to develop a machine learning strategy. Starting simple is important, and only adding complexity when it is necessary.