English | EN 
The world around the DevOps team is changing. It is accelerating constantly to a new world where the practices are complete different as it is today. DevOps teams need to evolve accordingly to stay relevant.
Adapt or perish, now as ever, is nature’s inexorable imperative. (H.G. Wells)
To know in which direction to evolve, it is important to know what the drivers are which influence this change.
Three forces are pushing the DevOps continues evolution:
- The Cloud Platform force.
- The System Architecture force.
- The Collaboration Force.
Note: a common practice in larger systems is that multiple DevOps teams are supported by a Service Delivery Team. A Service Delivery Team helps teams with knowledge, work and artifacts. For example, when a team isn’t that comfortable, knowledgeable about cloud infrastructures. The Service Delivery Team helps by setting up environments and configure releases. They help the team to not slow down. Next to the DevOps Teams also the Service Delivery team are directed by the forces.
The Cloud Platforms Force.
The ever progressing capabilities of the platform are strong driver of a changing DevOps world.
An Ops team traditionally coming from an on premise situation, where they are most comfortable in managing, maintaining, monitoring, patching, provisioning and releasing machines. These machines live in a network with a lot of cables and flickering lights, somewhere in a datacenter. Safely giving service level agreements with many nines because everything was in the control circle of the team.
With the ever growing cloud platforms this changed.
IaaS.
The first capabilities of cloud platforms existed out of machines, Infrastructure as a Service. The change for a team to start using IaaS environments isn’t too big and the learning curve not too steep. The team needs to learn the do’s and don’ts for Cloud and for the rest of the knowledge and practices they can reuse it from the on-premises situation.
The biggest change in knowledge you see is that developer oriented team members have to learn infrastructure configurations. For the Ops oriented team members all work is the same as on-premises.
Containers.
Cloud platforms evolve and new capabilities are added. Not only new capabilities but also new possibilities and new service delivery opportunities. One technology is getting an enormous adoption, container based systems.
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.
While container systems make the life of the team much easier. They can move very easy containers around and create new ones. From an operational perspective there isn’t a big difference with IaaS machines. The container host infrastructure is a machine with an operating system and networking needs. The same for the containers which float around. As Sumlogic one of the vendors who jumped in the maintenance support of containers:
Docker allows you to quickly and easily deploy hundreds or thousands of containers with minimal overhead. But once deployed, managing and tracking that environment can be a challenge. How do you know: • Which containers are using the most system resources? •Which containers are down? • How many containers are currently running in my environment?
Also the Docker paper “Delivering agility, portability and control with Docker Containers as a Service (CaaS)” visualizes the operational work to be done.
Containers make the life of the developer activities within the DevOps team much easier, there is a minimal knowledge needed to create a new container. From operational perspective it is challenging, container host and container management activities need to be adopted.
PaaS
Cloud platform capabilities for Platform as a Service (PaaS) like Azure Cloud Services, Google App Engine and many more (see this PaaS comparison guide), change the operational playing field more as container services.
Simply saying, there is no need for maintaining and monitoring the infrastructure and operating systems with PaaS capabilities. But that is a too easy conclusion.
The PaaS cloud capabilities are bringing some additional complexity. This complexity is the level of PaaS the different cloud platforms provide. Some offerings are very close to IaaS some are closer to SaaS. For example, RedHat OpenShift is more an IaaS solution than PaaS (see the PaaS comparison guide), with the corresponding maintenance and operational activities needs, like an IaaS solution and container service.
Within Microsoft Azure this distinction is clearly visible when looking at Azure App Services versus the classic Azure Worker en Azure Web Roles. With the Azure Worker and Web Roles there is more customization, tuning of the service (firewalls, network etc) as in the App Service. An Azure Worker Role is actually a virtual machine.
When looking at Azure Web App services, websites which can be maintained and monitored via default maintenance tools. Like logging and Azure application insights (see this monitoring post). Also auto scaling can be configured. All monitoring you generally do on a website also can be done on a PaaS service like Azure Web Apps services. The only thing what drops off is the operational activities on the platform (update, patching), this is done by the cloud provider.
See the documentation on Azure App Services and the mange and monitor capabilities here.
Generally, the closer a PaaS solution is to IaaS the more traditional operational activities are needed, the more PaaS it is less operational activities are needed. But still most PaaS offerings by cloud providers aren’t that different to maintain than the old on premise hosted website.
Serverless Platform.
The ultimate PaaS services are the so called Serverless Platforms. No need to invest any knowledge in the platform, all is maintained and organized by the cloud provider, network, scaling, etc. The only custom thing that runs on that platform are functions. The platform takes care of the scaling, network and other.
Definition from https://www.thoughtworks.com/radar/techniques/serverless-architecture
applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party.
Azure Functions, Azure Service Fabric, AWS Lambda, Google functions and IBM Bluemix OpenWhisk are Serverless Cloud Compute platform services, real Platform as a Service.
The operational needs of systems build on a serverless platform are different as with traditional IaaS and PaaS solutions. It requires the monitoring of the functions, how they behave, this means monitoring the core functionality of the system and not the platform anymore. From: How Serverless Applications Will Change Your Business.
In the future, said Emison, the enterprise IT staff developer will be focused on constantly improving the logic of the customer’s interaction with the business, instead of figuring out how to set up and maintain a database server and other infrastructure issues.
Other Cloud offerings.
Not only Virtual Machines and App Services like Azure Web apps are part of Cloud offerings. But there is a width variety of services offered by cloud providers. All with specific operational and management needs.
For Microsoft Azure these service are:
Most services are PaaS solutions and all require specific maintenance and operations. For example, a PaaS SQL Server still needs traditional SQL maintenance. Just as the other storage options like Blob storages and DocumentDB require specific maintenance and a Message Bus requires control over the message which goes through the bus.
When looking at all these services, all need to be supported by the DevOps team. This requires specialist knowledge. Where traditional operational teams still can handle Virtual Machines, Azure AD and Networking, now they also need to have knowledge about the operational and maintenance needs of a Machine Learning implementation, and about Big Data solutions like Hadoop or Azure IoT Stream Analytics. Challenging.
The Architecture Force.
Not only the cloud platform capabilities are the changing force on the DevOps team (although, the force is strong with this one), also a pushing force are the architectural patterns (archetypes) used for systems.
The architecture already moved from big monoliths, with operation people in white doctor coats, to a focus on loosely coupled systems. Vertical decoupled via the layered architecture, evolving to vertical separated functionality with Service Oriented Architectures.
The central developed, maintained and updated relational database moved to separate services in NoSQL storages. The responsibility of central Enterprise Service Bus is handover to the API service endpoints.
From a one stop shop deploy and maintain environment to a microservices distributed system design, multiple distributed pieces of functionality with isolated responsibility.
See the Microservices Resource Guide
Development knowledge need to be adjusted to these new designs and also operational activities are changing, all for faster changeable, loosely coupled, single responsible and fast deployable systems.
From Microservices at Spotify:
He argues that Microservices are easier to test, deploy and monitor than monolithic applications. Spotify also aims to have as few as possible dependencies in their product, and microservices are very helpful for that.
With rise of the amount of services also the amount of integration increases. Architectural Integration patterns are getting more important, and also the operations of these loosely systems are getting more complex.
From Netflix blog:
At Netflix we pioneer new cloud architectures and technologies to operate at massive scale – a scale which breaks most monitoring and analysis tools. The challenge is not just handling a massive instance count but to also provide quick, actionable insight for a large-scale, microservice-based architecture.
Cloud providers are offering more and more capabilities (see list previous paragraph, serverless platform) which makes the micro-services distributed system design possible and easier for teams to implement. They can choose the best offering for their system needs and combine them together to the ultimate solution. Systems will exist out of a blend of Cloud services to support the ultimate scenario. Combinations of PaaS, SaaS and IaaS with on-premises systems aren’t strange anymore.
A system architecture with an optimal blend of Azure resources. See Building a DevOps Assessment tool with VSTS, Azure PaaS and OneShare in minutes.
This architecture force, of breaking down systems in independently deployable services with their own versions, their own responsibilities and a specific supporting cloud offering, also needs different operation and maintenance needs, which also need a changing focus of the DevOps team. From releasing components through an OTAP environments systems to an in production canary tested microservices system.
The Collaboration Force.
Number one business focus is agility, faster and flexible business systems. The Cloud Force helps to accomplish this goal with their platform capabilities. The Architectural force of breaking down systems in smaller ones makes updating small business functionality easier. But this isn’t enough. Also the DevOps teams realizing the business value are an important force with evolving insights and practices.
Mainly the culture part of the development of systems have changed. Now teams have the mindsets of build better products by being closer to the customer and be more flexible and faster by grouping in cross-functional teams. Actually not that recent change, because these cultural practices are coming from the 15-year-old agile manifesto.
DevOps Teams are coming from traditional DTAP environments. Releasing a new system sequential over all these environments, with all the signoff phases, is very slow and expensive. See: The Time of DevTest Labs is over. DevOps to the Max.
Practices adopted by many teams are almost all focused on shorten the release cycle. DevOps is the catalyst for these practices. DevOps practices for example contains, Infrastructure as Code and the corresponding practice Immutable Servers. Both have a high impact on the work of the DevOps team, Treating Servers as Cattle, Not as Pets. Containers, initially invented for speeding up DevTest scenario’s , is another one. DEvops practices like this, quickly provision new environments, make it possible and comfortable to work, collaborate, with the customers of the system and the business owner.
Other practices like Feature Toggles, Testing in Production, A/B testing and canary releases are making it possible to completely skip the need for development and test environments and focused on business features, direct used by customers. Due to the direct interaction with production these practices have a big impact on the DevOps team from an operational view, monitor what happens with the new feature.
Controlling the complexity, staying flexible and continues communication are important drivers behind the collaboration force which needs adoption company wide.
Tips to stay relevant as ops and dev.
The area of traditional infrastructure maintenance and development of systems is over, DevOps is here to stay and to evolve to further optimization. Three forces are pushing the development, operational and maintenance needs by systems in a new direction. All with the focus on faster and more flexible business value. Operations and development teams need to adapt to this change and support this unstoppable evolution. Not only to stay relevant but also because teams need their support.
Some tips for DevOps teams to stay relevant and adapt to the evolution.
Adopt faster or choose.
The evolving cloud platform capabilities require constant learning and adoption. DevOps teams and supporting services need to have a system, a mindset, of constant change and constant adoption of new capabilities. The challenge, do this fast and do this without losing old habits and knowledge.
Finally, a decision should be made. Cloud platforms will evolve with many new capabilities. These capabilities will be more than a DevOps team and Service Delivery team can handle. Narrow down what is supported out of the box and have a plan how to adopt new ones is a choice. Dedicated technology focused DevOps teams will be necessary, mastering the details of one technology. A move to vertical specialism is also already happening.
Monitor Business Process.
The architectural force together with the cloud platform capabilities to run microservices on serverless platforms is a big change in knowledge needs. Microservices are small business services. Serverless platforms don’t require much deployment and maintenance. Fast deployment capabilities of these serverless platform microservices need to be adopted by DevOps and business teams.
The challenge of the fast changing business services is the impact on the business process, how is it interacting with other services. How is it used by end users or other services? This business flow needs monitoring too. DevOps teams are getting closer to the business by monitoring their process, not to slow them down but interact just in time.
No SLA option.
When a team can release direct to production it is hard to come up with a Service Level Agreement by operations. Blocking the team from doing it is the first thing that comes to mind of the business, because no SLA can be given on a system under change.
Remove the SLA is the only option and replace it by something else. Monitor the capability of the team to deliver software (see also next topic) and monitor, proof the robustness and quality of the running system by continuous monitoring.
Measure DevOps maturity.
Business focus is not only about the production environment anymore. Business is also about influence the development. The DevOps team is capable of pushing new business features to production, continuously. In the past there was an SLA to give the business a comfortable feeling.
When the SLA is removed the DevOps team needs to proof that the team is mature enough in delivering software, new functionality to production. A DevOps team which can offer this to the business are ahead of the game. They can offer the business fast and flexible business value with the comfortable feeling of a SLA.
Be the Digital Platform.
Offer the business the power of a digital platform for their business is finally the key to stay relevant. Provide business and their customers easy to use, stable, pluggable and reliable services (API’s) where new business value can be constructed, combined by business them self. No need for the business to talk technology, talk value and be that digital business platform as a DevOps team. See or report on Design to Disrupt: New Digital Competition & Platform Disruption from VINTlabs | The Sogeti Trendlab
