devopsy.kinsta.cloud

Tag: Administration

  • Key NoOps Insights From DevOps Leaders

    Key NoOps Insights From DevOps Leaders

    NoOps is coming, in some form or another. Whether you have homegrown DevOps or outsourced DevOps, it’s time to realize that a simpler way is coming: NoOps automation. We spoke with a group of IT pros to get their perspective and insights, including James Rutt, CIO, The Dana Foundation; Rahul Subramaniam, CEO, DevFactory; and Mark Hahn, director of DevOps and cloud strategies, Ciber Global.

    Forrester Research defines NoOps as the goal of completely automating the deployment, monitoring and management of applications and the infrastructure on which they run.

    The next generation of PaaS platforms is evolving to meet this goal. If development teams prefer not to deal with operations or lack the necessary skill sets, they can opt into platforms that provide standardized best-in-class operations with minimal hassle. This also accelerates the evolution of their infrastructure to emerging technologies such as Kubernetes and containers. Not only that, but it can be accomplished at a fraction of the cost. However, the NoOps concept is not without its own bit of controversy.

    Insight #1: The End Goal is to Empower Development Teams

    Mark Hahn: “The differences [between DevOps and NoOps] have a lot to do with shifting left more on all of the processes. With DevOps, teams have to rely on various operations and infrastructure support services. With NoOps, the goal is to make those teams fully self-sufficient.”

    Automation is the key to this self-sufficiency. Continuous integration and deployment automation can be created and configured by the DevOps team or provided by the platform (NoOps). In either case, the end goal is to empower the team such that they can focus more on the business problem at hand than deployment.

    In a DevOps model, a few developers on the team typically manage the continuous integration pipelines and their associated deployments. This includes the creation of the application stack and subsequent updates, as well as observability and scalability mechanisms. The widespread availability of infrastructure-as-code and associated APIs has made this possible.

    NoOps platforms provide these capabilities without much additional work by developers, thus enabling application teams to accelerate their delivery velocity. This does come at the cost of some flexibility. Teams with special requirements, such as GPU-centric environments or extremely high-scale use cases, may opt to build their own infrastructure to meet their individual needs.
    Most teams don’t need the additional complexity, though, and are better served to avoid it. Applications with a user base in the low thousands will likely not need much beyond the standard configuration provided with frameworks such as Spring Boot or .Net Core. You start with just the infrastructure you need, avoid solving problems you don’t have and leverage only select offerings from cloud providers.

    Insight #2: Consistently Making the Right Infrastructure Choices is Hard

    Rahul Subramaniam: “We have far too many choices; making the right choices is extraordinarily hard. When you build a Spring Boot application, the number of deployment choices you make is ten times what it was even five years ago.”

    “I’ve seen teams that put together really large CI/CD pipelines that run thousands of builds a day. The problem is, it works for 50% of the teams really well, and the other half are struggling. For developers building Java-based systems, it works great, but those that are doing Android development, it doesn’t support mobile applications well,” added Hahn.

    The NoOps approach has a key dimension that extends beyond automation. The infrastructure landscape is continually evolving, and developers are faced with a growing array of choices as they deploy and manage applications. How can teams know which are the right tools to pick? There are too many out there to be an expert on all of them.

    Consider the area of observability, where choices range from open-source solutions such as Prometheus and Grafana to commercial offerings such as Dynatrace and DataDog. Is the extra value added by the commercial offerings worth it? Is it a requirement for your application?

    It can be difficult to say, upfront. Oftentimes, the best way to learn how to operate your service is to operate your service. Starting with an opinionated, bundled solution gets you started quickly and puts you in a position where you can learn those lessons. With NoOps, the infrastructure arrives ready-to-go, right out of the box. You can focus on your core business function and not worry about the deployment mechanism. This shrinks the surface area where errors may occur, and improves the efficiency of development teams. From a management perspective, the reduced cost is also quite appealing.

    Mark Hahn offered a different perspective on this topic. He noted that if there is one opinionated CI/CD framework, it may suit some teams well but not the others. Teams that develop various components may have different requirements; thus, they may need the option to build their own pipelines. This is a consideration to keep in mind as organizations seek to adopt the NoOps philosophy.

    Insight #3: Evolve from NoOps to DevOps, Instead of the Reverse

    James Rutt: “There is a broad assumption that DevOps is mature, whereas in most shops, they feel mature in some areas of the value stream but not necessarily in the synchronization of all the tools. Now, we are talking about another quantum leap into NoOps. Do you think we are jumping ahead too quickly?”

    DevOps and NoOps represent a spectrum, rather than a conflict where one wins over the other. Many applications don’t need a highly engineered infrastructure, as opposed to companies like Amazon and Netflix who require it. Thus, don’t over-architect solutions until the time where you need to. Grow into DevOps when it becomes a business priority for you. For Amazon, it is a business priority to manage that infrastructure. For you, it may not be.

    Subramaniam made the point that teams should actually begin with the NoOps approach as the default. Look for NoOps solutions out there to quickly get started, and at some point, you may need to manage that infrastructure yourself as your business grows or requires it.

    Another consideration is that not all organizations are at the point where developers can make choices independently. You always want the business and technology groups to be in alignment. This is where more traditional processes fall into place. Further, DevOps teams typically place numerous checks and balances in their systems. For example, custom pipelines enable reconciliations and cross-checks to make sure the data being operated on is correct and accurate.

    Insight #4: NoOps Platforms vary by Cloud Provider

    For developers running on Google’s cloud, App Engine “lets app developers build scalable web and mobile back ends in any programming language on a fully managed serverless platform.” Teams running on AWS can use Engine Yard Kontainers from DevGraph to “deploy apps in one click directly from your Git repo.” There is also AWS Elastic Beanstalk, which bills itself as “an easy-to-use service for deploying and scaling web applications and services” on one of their supported technology stacks.

    Regardless of DevOps versus NoOps, our interviewees agreed that development teams need to be empowered. Gone are the days where you can afford to spend time on undifferentiated activities or wait on dependent service teams. Focus on the business value from day one, make it observable and use the platform that best enables you to accomplish that goal.

  • The Beauty of Inheritance Architectures

    The Beauty of Inheritance Architectures

    Spoiler alert: This article is not about inheriting your great-grandparent’s estate. It is rather about how embedding the principles of inheritance into the architecture of your chosen DevOps toolset can yield exponential results. And yes, I realize that you, the customer, have little to do with what a vendor builds its tooling architecture upon. However, you, the customer, can vote with your feet, to search out products that offer features such as inheritance, rewarding vendors that have it and punishing those that do not. The simple question to address here is, Why should the customer care?

    Like anything that can grow, sustainability on scale is a key concern. How much will it cost me when I am maintaining 6,000 applications on this particular DevOps toolset, as opposed to the six applications I started with? You can also infer maintaining a higher number of technologies as having the same need. For example, if I need to maintain three different types of databases, two different middleware, four different hardware platforms on “x” different versions of operating systems … you get the idea. The larger the application portfolio (in sheer numbers of apps), or the more technically complex the portfolio (in sheer numbers of technology components in an app), eventually will drive you to worry about how easy it is to maintain these applications within your chosen DevOps toolset.

    The capabilities of your chosen set of DevOps tooling will govern the costs of both the initial adoption of your services as well as the ongoing maintenance of the application portfolios you serve. It is hard to sell the value of DevOps to the business when it begins to see a one-for-one increase in DevOps engineering staff for every new application or technology venture under consideration. However, one of the chief culprits in driving large DevOps support staff organizations boils down to the lack of an inheritance architecture in the tooling that was originally selected.

    Setting a Common Language

    So before we discuss how inheritance will benefit us, first let’s agree on a common vernacular of what an “application” is. When you say the word “app” to someone, you get a wide variety of responses on what that means—from something that sits on your phone to a cluster of things that sit on the mainframe. Let’s begin by examining what an “app” is by the effort it takes to onboard and then maintain it on our DevOps sets of services (regardless of platform).

    Consider for a moment the hierarchies by which we could describe software constructs. It is relatively easy to discuss how software works in terms of hierarchy. First, at the lowest layer, we could describe having multiple technology components (or the lowest level of a particular piece of technology that must be addressed in a build). Next, assembling these components together forms the picture of what a single application looks like. Finally, assembling multiple applications that have a common symmetry or common purpose together form a system or series of apps.

    An imperfect but quick example could be the Microsoft Org Chart component of its Office application(s). For purposes of example we will argue that Org Chart, Clip Art Manager and Equation Editor are all components of the application Microsoft Excel. To build a new version of the application Excel, we would have to deal with each of these individual components that, once assembled in our build, would create a new version of Excel. When you combine more of the apps—Excel, Word, Outlook and PowerPoint—you get the system, or series, called MS Office. (And, yes, I know this is a less than ideal example, but it is meant only to illustrate a point.)

    Assessing the Work Effort

    The reason for discussing software in this way allows us to begin to discuss the level of effort to automate it. By addressing the work effort to automate each component (by type), we can begin to estimate how long it will take to complete “the automation of software.” For example, if my homegrown application has a source code component, a configuration file component, a database component and a middleware component, then I have four components I must automate (or include in the build and deploy process) to assemble a new version of my application.

    This gives us a “least common denominator” language for assessing how much effort it takes to automate a given app. I have seen most common applications have only two to three components. But I have also seen several apps that, due to their unique architecture and construction, have 30 to 50 components a piece. Obviously, it is easier to automate an application with only three components than one with 50 components. The other factor we need to apply on the ease of automation is whether I have encountered this particular component technology before in my prior automation efforts.

    Let’s say, for example, that the application I am estimating contains Java component(s). If I have encountered Java automation prior to this, I should have constructed a template for Java type component automation that I can use for a situation just like this one. In this situation a familiar technology component is far easier to automate than a new one (or, rather, new to me). However, if this is the first time I have ever seen Java, then it may take me a bit longer to construct the template I want for this app, and for future apps I encounter, that also use this technology type.

    The Beauty of Inheritance

    Here is where inheritance begins to play its critical role. If my DevOps-build construction tooling includes inheritance, then I could construct a “master” template or framework for each type of technology as I encounter it. A master template for SQL databases or Oracle or DB2, as an example. Or, I could make a master template for WebSphere or SharePoint types of technologies—one master for each kind of programming language we have in my shop. You get the idea.

    Having done this allows me to have a limited number of master templates, in which I can maintain all the critical steps and processes my company wants me to do for a given technology type. If different business organizations or development organizations need a variation, they can create a “child” of my master and vary it according to their own needs. As long as the linkage is maintained to my parent/master template, I can make the big, overarching changes driven by corporate mandate, and the business unit can continue to vary items to their unique needs.

    Having inheritance in this instance allows me to roll out changes to an entire organization, such as, for example, a security patch or process, for a given technology by simply adjusting the master template of that component. Inheritance automatically flows my change down to all the “children” of my master and possibly to all their “children,” should the need arise. The alternative is having to go through the specific automation of each application that has the targeted technology component and updating it manually, hoping I don’t miss one, and hoping the steps I may need to adjust do not break the old automation instead of alter it the way I needed.

    Imagine having a WebSphere subject matter expert able to adjust every client application that uses your corporate installation of WebSphere by simply adjusting one master template. Or having a network guru, or database expert, be able to do the same for all applications that use their particular technology component all at once. Inheritance preserves the real-world need of having limited alterations of the same technology type within the same company, flowing down changes from parent to child.

    Having a one-size-fits-all is simply not practical. Using copy/paste requires repeating updates to each impacted template or framework manually. But having the ability to create offshoots from a main, and not lose the connection to the main, allows corporatewide alteration from a central point of control. The costs of maintenance or administration are formidable; inheritance can reduce them. This allows a much higher ratio of applications or technology components supported by a much lower number of engineering staff.

    A Wider Impact for Inheritance

    Inheritance is keenly useful in release orchestration software as well. Most vendors offer the cut-and-paste approach: you copy the last the release you did, alter it slightly and use it again. That might work for some organizations. But having an inheritance feature creates entirely new dynamics on how a release is constructed for a given line of business and how corporate governance can be implemented with minimal effort. In this case, a corporate master release template can be constructed, and child releases can inherit from the master all the main governance required without risk of omission.

    I realize inheritance architectures might not be at the top of your list when evaluating DevOps tooling solutions. But I would submit it is a strategist’s job (if you need one, let me know, I am looking 🙂 ) to point out how long-term sustainability can be greatly benefited by this architectural feature—even if the vendor would love nothing more than to steer you away from it. If you already have committed to a tooling solution, you may want to bring this up at your next vendor features performance meeting. If not, you should at least consider what having it means to your internal cost structure, and what not having it will add to the true cost of ownership of any proposed solution.

    To continue the conversation, feel free to contact me.