devopsy.kinsta.cloud

Tag: Evolution

  • Does Platform Engineering Make DevOps & DevSecOps Irrelevant?

    Does Platform Engineering Make DevOps & DevSecOps Irrelevant?

    For those of us old enough to remember, the DevOps movement came onto the scene somewhere around 2007/2008. Its proponents railed against the traditional software model at the time, which called for the developers who wrote the code to be organizationally and functionally separate from those who deployed and supported the code. The reasoning behind the movement is that these siloed teams, concerned only with their own objectives, resulted in botched releases, significant delays, poor communication and, ultimately, unhappy customers. It took a few years to gain traction, but when Gartner got on board with the concept in 2011, adoption soared, and Agile development practices like automated build and test and continuous integration and delivery became the new norm.

    Security and Compliance Join the Mix

    Agile, DevOps and its promise of continuous integration and continuous delivery … well, delivered. Development and operations teams were finally on the same page, each able to see a current phase’s end goal, providing the flexibility to make changes and improvements along the way, speeding the delivery of quality software. Unfortunately, in these early years of DevOps success, security and compliance generally remained siloed. That silo resulted in security being an afterthought—stuck near the end of the application development life cycle. Consequently, security took the blame for release-delaying bottlenecks.

    The year 2014 was notable for an exponential increase in security breaches compared to the year before. According to an article in Security Week, 2014 marked the year that, for the first time, one billion records were compromised in more than 1,500 notable data breaches, an increase of 80% from 2013. Home Depot, JP Morgan Chase and eBay were among the many exposed to attackers. Given these and other high-profile breaches, it was time to re-evaluate development processes and give security and compliance a seat at the table.

    With research by Microsoft and others showing that 80% of security breaches were related to configuration errors, the concept of DevSecOps, putting security front and center in the Agile development process, ensures that assets are configured correctly in the first place, providing continuous compliance by running constant scans to identify configuration drift.

    This approach can be extended beyond the data center to any cloud to any edge, where even applications can be managed and checked against compliance and security standards. You can even extend a single DevSecOps compliance framework to cloud native assets including Kubernetes and public cloud services. 

    Today, it is safe to say that the term “DevOps” is likely losing its relevance, but “DevSecOps” is alive and well, as long as the organization embraces the cultural, people and process changes necessary for success. Tools and technology are essential to DevSecOps, as is adopting a culture that security is everyone’s responsibility. That culture requires instigating a security-first mindset among teams as well as implementing essential automated security testing tools.

    What About Platform Engineering?

    Platform engineering has recently captured interest and is now generating considerable buzz due to its focus on building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management. The platform is supported by layered services or tools, created and maintained by a dedicated product team, designed to support the needs of software developers by essentially stitching together components to create a frictionless developer experience.

    As Gartner says, “Platform engineering is an emerging technology approach that can accelerate the delivery of applications and the pace at which they produce business value.” In fact, Gartner expects “[t]hat by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery. Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.”

    In that context, platform engineering certainly builds upon the Agile concepts of DevOps and DevSecOps. Looking deeper at DevOps/DevSecOps and platform engineering shows that they both share many characteristics, while they can also be combined in a way that provides greater benefits to organizations that think about them in tandem. It is easy to see the integral link between platform engineering and DevSecOps and the broader infrastructure management landscape. For example,

    • Developer Experience and Productivity – DevSecOps extends experience and productivity support beyond the developer to IT Ops, security and compliance.
    • Automation – Automating infrastructure configuration as well as compliance tasks using a policy-as-code approach is the lynchpin of DevSecOps. Platform engineering provides the opportunity to extend automation to the other parts of the development lifecycle.
    • Self-service – This is another common concept where platform engineering can build off of the automation and services-oriented approach that DevSecOps uses to not only enable developer self-service for code/test/deploy, but also to enable developers to be more proactive and effective in the security/compliance realm.
    • Accelerate Value – Accelerating value is the focus of any tech enabler, from platforms to tools and processes.

    From an Agile development approach supported by DevOps/DevSecOps and extending now to platform engineering, the end game is all about speeding delivery of high-impact applications with continuous updates that are highly resilient, reliable and secure. Given the synergies and the pressure on organizations to rapidly deliver applications while combatting cyberthreats, any platform engineering effort should ensure that DevOps/DevSecOps plays a central role.

    While the term DevOps and, to some extent, DevSecOps, sound a bit dated and irrelevant and could maybe use a new moniker, the evolving role they are certain to play as platform engineering gains a foothold are not to be underestimated. 

  • Experts Weigh In on the Evolution of DevOps

    Experts Weigh In on the Evolution of DevOps

    DevOps is an ethereal concept. It means different things to different organizations and individuals. It also is going through an evolution, which means that as quickly as we might think we have a grasp on what it is and how to effectively employ it, DevOps has moved on. There’s no way to accurately predict whether DevOps will even still be a thing in another five years, or if it will have faded into oblivion—replaced by the next hot tech or development model. We can, however, take a look at how DevOps has changed in the past year, and what the immediate future holds for it.

    It isn’t an easy question to answer because first we have to agree on what DevOps is. Are we talking about DevOps as a culture or business model, or are we referring to the evolution of the tools and applications generally used in a DevOps environment? I reached out to the DevOps community to get some expert insight.

    Current State of DevOps

    “The technology question is a common one when it comes to DevOps. We are still faced with the problem of a clear definition of DevOps. So what makes this difficult is … I’m squarely in the camp that believes DevOps is more about culture than tools or tech,” explains Andrew Storms, vice president of Security Services at New Context. “That being said, a well-rounded and mature DevOps organization does require a shift in people, processes and technology. A lot of people will likely point to orchestration of infrastructure as the most important DevOps tool. However, I think the bigger driver of orchestration has been virtualization and cloud.”

    One of the defining characteristics of DevOps from my perspective—aside from the IT culture aspect—is the fact that we continue to raise the bar for automation. Each new automation tool further streamlines the process and puts a spotlight on the next bottleneck. Eventually, a new solution is developed to automate that as well.

    Chef CEO Barry Crist believes that one of the most important evolutions in the world of DevOps in the past year is continuous delivery (CD)—or the process of rapidly developing software and iterating through quick, small-batch releases. “Continuous delivery was previously exclusive to the web innovators like Facebook, Amazon and Google, but over the last year companies have realized it’s a primary key to unleash an organization’s innovation engine. When the whole stack—infrastructure, compliance, security, microservices and apps—are all expressed as code, IT is able to deliver value more quickly.”

    DevOps also has introduced more common ground between developers and security/compliance officers. In high-velocity organizations that have embraced DevOps, IT can deal with security threats more quickly by assessing a vulnerability, creating a fix, testing it and deploying it rapidly before damage is done. DevOps is also starting to automate and define compliance. When compliance is defined as code, the software can be managed and tested like any other piece of code in the organization.

    The Evolution of DevOps

    Storms stresses that the immediate future of DevOps revolves around it becoming more mainstream—the new normal. “We are already seeing the business value of DevOps. Companies are getting code out the door faster and at a more efficient means. Other departments, like those of security, are starting to see the value of DevOps and looking at ways to incorporate key points into their departments,” he says.

    Crist sees DevOps as evolving beyond IT itself. “In the next few years, the DevOps tent will expand beyond ‘devs’ and ‘ops’ to include executives and other business units,” he says. “DevOps is really about building high-velocity organizations. Mature DevOps organizations see both innovation and quality increases that drive more profit and shareholder value, as well as advances in security and safety.”

    Only time will tell how DevOps will actually adapt and evolve. I tend to agree with Chef’s Crist that the natural evolution is to take the core principles and practices of DevOps and expand them beyond development and beyond IT to streamline all aspects of the organization. I guess the real question is whether or not we’ll still refer to it as “DevOps” at that point.

  • Parallel Evolution of DevOps Enterprise Patterns

    Parallel Evolution of DevOps Enterprise Patterns

    The DevOps evolution (Revolution!) has a great story; a story of winning the hearts and minds of people of all experiences who all anxiously strive to achieve their goals in amazing new and opportunistic ways. This story isn’t that of throwing everything away and starting over, nor is it a story of always having to start from scratch and do things from the ground up. It’s a story that reflects the hard work, critical thinking, scientific processes and deep analysis of your business needs with your goal in mind.  The concepts of the classic DevOps cloud business and the classic Enterprise all evolve in different ways but end up with the same evolutionary cognitive artifact, the focus on improvement and adding value through technology.

    When it comes to talking about Enterprise patterns vs the more spoken about “Cloud” patterns, we sort of speak to them as if their exclusively different, almost denying them an existence by choice.  One sees an “Enterprise” shop and almost cringes at the thought of them being DevOps out of an ideological view more than an evolutionary view.  However, when studying a “DevOps Enterprise” and “Cloud” company  from the ten thousand foot view we can see them as being much more similar.

    Cloud Patterns

    Develop -> Build -> Test -> Deploy

    Enterprise Patterns

    Develop -> Build -> Test -> Deploy

    Visually, this pattern while overly simplified is the same but how people get from develop to deploy may be entirely different.   In a developer centric “cloud pattern” you may be developing a web application to offer self service functionality to your end users but in a corporate environment you may be less developer centric as a business analyst adding features in a corporate resource planning application.  The end result is still creating value for your customer, developing functionality, building that functionality, testing that functionality and deploying that functionality and doing so in a very “DevOps Way”. Taking a closer look at the Enterprise through a slightly stronger magnifying glass, we would see something more like this for a typical enterprise deployment pattern:

    Storage -> Physical Host > Hypervisor ->  Virtual Host -> Database  <-> Application -> Customer

    Everything that composes this pattern could be made of of all sorts of parts from many vendors, open source projects, COTS systems and value add resellers. The components aren’t really what matters.  It’s the technology that an organization has acquired in doing business and the processes they have developed to meet the demands of their organization over their years of growing. It’s grown organically just as our concepts of IT have grown over there years and its done so creating and growing value too (at least, that’s the expectation). It’s evolved.  For better or worse, there is something we’ve encoded in these concepts and transmitted in an artifact we call “Enterprise”.

    The end result of applying DevOps to an Enterprise “Develop -> Build -> Test -> Deploy” pattern is to add value to this pattern, align this pattern to the business and to optimize the flow of this pattern. It’s really no different than applying these ideas to a “Cloud” business. One could optimize the Enterprise pattern of their Oracle Financials application by doing continuous integration just as cloud operations strive for continuous integration, but the CI you see in Oracle world  may be drastically different than that of typical Cloud Ops CI. Enterprise CI may be more of a “validation” experiment, a “Safe to fail” experiment. It may be more business process oriented – you may see people experimenting with BPEL or other tools to wrap business requirements and compliance around tasks/alerts/metrics/services/data.  The more we talk about Enterprise DevOps patterns the more we realize that we can benefit from these experiences in all DevOps patterns! There is a lot we can parallel in our views and see value from. Just because the “Enterprise” and the “Cloud” may appear differently, doesn’t mean they’re exclusively different by mandate or incapable of converging ideas.

    Looking more closely at the Cloud, we see this a mode of operations:

    Virtual Host -> Database  <-> Application -> Customer

    More frequently, depending on which type of cloud you seek out, you could simply see:

    Database  <-> Application -> Customer or simply just  Application -> Customer

    I feel it’s important to look at this evolution as parallel or even somewhat convergent (the differences being arbitrary if you ask me) because the end results are the same, that all-powerful “Goal”.    How one gets there, is how you tell your own story, but that story is your own evolution of services and what worked for you and your survival. The common hereditary artifacts of this separate but in the end parallel evolution of services is that they appear to build upon each other; sharing similar services, using APIs, using abstractions when needed, using automation when needed, building up “self-service” type systems/frameworks and doing so with the end user in mind and creating value (surviving!). To the customers in an Enterprise business, all they see is “application” or “service” just as in the cloud services organization your customer  sees “application” or “service”.  DevOps is the patterns that create/add value/optimize flow regardless of the service to the customer.

    Some people call the Enterprise applications and services we all know so well as the “Dinosaurs” of the computing age. Let me remind you, dinosaurs ruled the earth for 230 million years;  that’s 229+ million more years than humans! Dinosaurs weren’t stagnant by any means, they continually evolved and grew with staggering variations and abilities to survive.  If you stopped evolving, you went extinct.  Beyond the extinction of the dinosaurs, many species from the same era did survive and they survived not just because they had the winning combination of hereditary traits for survival but because they evolved through the changes that continued to happen regardless of their will to survive. Dinosaurs had an evolutionary dead end not because they did the wrong things or had the wrong design, but because couldn’t survive against the external forces that happened upon them.  The Cloud business could just as well be a dinosaur, soon to be extinct if that business fails to evolve for its own survival. Same for the Enterprise business.  We’re all evolved from dinosaurs in the end and if some have figured out how to survive through their cosmic collisions and still appear to outsiders as a metaphorical dinosaur, then that survival should be seen as having value in and of itself. The cognitive ability of reason should win, not an ideological opinion thereof.

    DevOps at “Big Giant and often cumbersome Corporation” may be different in scale/ideas, but the goal is just as much the same  and the experiences we can learn from each other, are just as much the same. Join my efforts in documenting DevOps in the enterprise, and help work on Enterprise DevOps patterns or DevOps Audit Defense concepts.  Both of these are open to participation and aren’t in any way specific to any technology or service other than sharing experiences that are common in the arbitrary “Classic Enterprise” or “Classic Corporate IT” shop.

    Through the parallel evolution of Cloud and Enterprise systems, convergence may be the end result, but it certainly isn’t the mandate. Keep evolving! Mother nature has done it for billions of years and she isn’t stopping anytime soon.