devopsy.kinsta.cloud

Author: Nati Shalom

  • Solving the Speed Paradox With Open Source PaaS

    Solving the Speed Paradox With Open Source PaaS

    The number of DevOps tools keeps growing, as does the number of cloud resources and options to manage those resources. On EC2 alone, AWS offers nearly 400 instance types across storage, networking and operating systems. Complicating this further is that users can choose from machines located in 24 regions and 77 availability zones.

    This proliferation is driving a ‘speed paradox’ wherein the faster you grow the more fragmented and complex your ecosystem becomes which, in turn, slows everything down. Most DevOps teams struggle to keep up with the demand for more environments from developers.

    The Speed Paradox

    The Rise of the Internal Developer Platform (IDP)

    One intriguing solution to the speed paradox is the internal developer platform (IDP). As its name suggests, an IDP provides a single place where developers can find all the resources needed to run their environments. An IDP allows developers to speed development processes by offering improvements in:

    • Efficiency – Simplifying access to development and testing infrastructure through a self-service experience;
    • Consistency – Providing a consistent way to consume infrastructure resources across teams; and
    • Visibility – Providing a single place to see all the pipelines, workflows and states associated with each environment.

    Gartner sums it nicely: “Product teams often struggle due to disparate tools and disjointed workflows as they accelerate digital transformation. Software engineering leaders leading platform teams must establish internal, self-service developer portals to enable consistency and scale cloud, agile and DevOps initiatives.”

    Lessons From the ‘PaaS-t’

    The idea of a developer platform isn’t new. Previous-generation PaaS—Google App Engine, Heroku Cloud Foundry, for instance—provided a simple interface to write applications by abstracting cloud resources. But early PaaS failed, perhaps mostly due to the long tail of developer needs. Back in 2013, I observed: 

    “Every Access project will eventually fail because, while 80% of what the user wants is fast and easy to create and the next 10% is possible with difficulty, ultimately the last 10% is impossible because you can’t get far enough underneath the built-in abstractions and users always want 100% of what they want.”

    You can sum up the failures of early PaaS in three points:

    • Too opinionated: It is hard (impossible?) to control the way the platforms run their infrastructure resources. You’re dependent on the platform vendor for customization.
    • Limited to simple web applications and language choices: Modern SaaS applications are complex and include backend services that don’t fit that architecture.
    • Maturity: Early PaaS attempted to abstract cloud when it was a young, moving target.

    What’s Changed?

    With early PaaS, we traded simplicity for flexibility. Finding the right balance between the two is the heart of the challenge. Kubernetes and Docker, as well as IaC tools like Terraform, Cloud Formation and Azure ARM are a great substrate: They provide a consistent framework to manage applications across a wide range of infrastructure resources among clouds. Maturity and adoption of these tools reduces barriers to build a developer platform. This opens the opportunity to create a custom platform for each organization, allowing teams to control how their platform fits into their organization’s environments. It also offers balance between simplicity and flexibility, because each organization can choose where to draw the line—and even redraw that line without being dependent on an external vendor.

    The next-generation platform 

    Enter Backstage

    Backstage is an open source IDP project led by Spotify. Its three main parts are:

    • Service Definition—Based on the Kubernetes template format, it provides a service descriptor that fits into a range of services: monitoring, CI/CD and Git repositories
    • Backstage service catalog—Basically a web application with a database backend providing a single point of access to manage resources
    • Integrated tooling via plugins —A marketplace of integrated resources

    Here’s how an IDP based on Backstage can look:

    An example of an internal development platform based on backstage

    We can use Backstage to organize all development services and resources such as our squad KPI, the development pipeline, API and Git repositories, all in one place.

    Turning Backstage Into a Full-Blown PaaS

    One of the missing pieces in Backstage is infrastructure provisioning. Adding it turns Backstage into something closer to a full-blown PaaS. Cloudify provides a remote execution engine that integrates with a variety of infrastructure resources and allows users to organize them into a self-service development or production environment. The integration of Cloudify into Backstage includes synchronizing the development environments into the Backstage service catalog and allowing self-provisioning of those services through the Backstage portal or through GitOps.

    Integrating Cloudify as a remote execution engine to Backstage 

    You can watch a demo or get more information on the integration from the Cloudify Backstage Git repo.

    The End of ‘Growth At Any Cost’

    Last year, Sarah Wang and Marti Cassado analyzed the impact of cloud spending on hypergrowth companies. As tech companies trade away efficiency in pursuit of velocity, they face a non-sustainable growth model where cloud costs surpass 50% of total revenue. Wang and Cassado’s analysis illustrates how this condition directly impacts a company’s profitability—and valuation.

    In today’s market upheaval, it’s even easier to see how a “growth at any cost” policy is unsustainable. Today, DevOps teams have to find ways to support growth while controlling costs. This forces organizations to better control how development teams use cloud infrastructure. 

    IDPs can become a major tool in this effort. Unsurprisingly they’re becoming the next hot DevOps trend. Backstage provides a great framework and ecosystem to shorten the time a team needs to build its own internal platform and Cloudify provides the open, remote execution engine with a single place to organize infrastructure resources into a self-service environment. The integration turns Backstage into a full-blown PaaS.

    The current Cloudify-Backstage integration is only an MVP release. Next, we’ll deepen the integration, providing more monitoring within the Backstage portal. Here, you can find more information on our open source contribution to Backstage and offer feedback.

    An Open Source Solution to the Speed Paradox 

    The “speed paradox”—where the faster you grow the more fragmented and complex your ecosystem becomes, which in turn slows everything down—need not grind our DevOps agility goals into the ground. By using open source Cloudify integrated into the Backstage project, DevOps teams can avoid becoming the new bottleneck in software development agility goals. 

     

  • Building on Terraform: Evolution, not Revolution

    Building on Terraform: Evolution, not Revolution

    Terraform is widely adopted among both enterprises and service providers who embrace infrastructure-as-code (IaC) as their model for infrastructure provisioning automation in DevOps environments. And while the technology has limitations, innovations seeking to unseat Terraform are highly fragmented and have seen tepid adoption. This points to a market that’s settling on a de-facto standard, so rather than trying to replace Terraform with the next great innovation, infrastructure operators should instead find ways to extend and augment Terraform to suit their unique needs. Let’s explore several of the better-known shortcomings of Terraform, some drivers for the rise in new alternatives to the technology, and what users need to consider when contemplating a different path.

    Without a doubt, Terraform is big. Across the big three public clouds, the number of Terraform provider installs tells the story: At the end of August, there were 457 million provider installs for AWS, and around 72 million each for Azure and GCP. Yes, compared to longer-in-the-tooth infrastructure configuration management tools like Ansible, Chef and Puppet, IaC as a category is still early. But, the trend is clear: IaC is becoming widely used at scale, and Terraform is the IaC platform most enterprises go with.

    It’s also no secret that there are shortcomings to Terraform. A quick search on Reddit and Hackernews unearths the litany of complaints, some more valid than others: 

    • It’s tricky creating a Kubernetes cluster and then adding a resource to it
    • Challenges passing values through a config or dumping a pure representation of an elevated config
    • Cluster deletion is a pain
    • An overall lack of visibility into what’s happening during the provisioning process
    • The need for glue code to drive everything is a drain on developer productivity
    • Lingering challenges with backward compatibility
    • Continuous update challenges and the need to refactor
    • Scaling across multiple workspaces and multiple cloud accounts
    • Rollbacks can be tricky, especially when dealing with immutable infrastructure

    Terraform’s parent company, HashiCorp, of course, steadily works to address these and other pain points. But the whole thing highlights an interesting question: Why is Terraform so popular?

    Terraform is the only IaC solution that meets the needs of developers who want an IaC tool that preserves state, fits well into their CI/CD pipelines, is intent-based and gives them the right level of granularity. Terraform, even with its challenges, is better than the alternatives in these regards.

    Here’s why: 

    Terraform was, from the start, designed for and targeted to developers. It maintains state and supports iteration, making IaC a powerful model for automating infrastructure. PaaS solutions, by contrast, are not robust enough for most developers who do not need or want all of the infrastructure decisions abstracted away. Most cloud management platforms suffer from the least common denominator problem, and even though the technology has improved in this regard, it’s a solution that developers generally abhor for its granularity; it’s geared more to the needs of IT management. Configuration management tools, as an alternative, are not intent-based, so flow becomes too complicated.

    It’s interesting to note that state (maintaining the mapping between the resources that you’ve represented in your definition files and the actual physical resources that are in the cloud provider) was added into Terraform, helping resolve the issue of infrastructure drift. Terraform also realized that developers don’t necessarily need a UI. These tangible examples of the developer-centric design ethos at HashiCorp point to why it is so widely adopted.

    So, what’s driving the interest in new approaches to infrastructure automation? The proliferation of domain-specific use cases and an ever-present need to reduce time-to-value are the leading reasons. Domain-specific automation options are becoming more dominant over OOB solutions because they take too long to get to automation; one tool does not fit all. Domain-specific automation addresses issues such as security automation, AIOps, DevSecOps, security compliance, integration with container scanners—not just generic orchestration. People are looking for value very fast, which can be found only with domain-specific automation—and therefore, fragmentation happens as different solutions emerge to address those cases.

    There are several interesting alternatives to Terraform. Terragrant is used along with Terraform to expand its capabilities to multiple workspaces. It allows you to use the same template across many environments. Pulumi is another alternative that has achieved a measure of adoption and visibility. It provides native code support which addresses the problem with YAML file development complexity. Another more ambitious undertaking is the Crossplane open source project. It takes a Kubernetes-centric approach to creating a universal, cross-cloud control plane. It looks good conceptually, but it’s a fundamentally different approach, and adoption is nascent.

    Turning to one of the Terraform alternatives isn’t necessarily a bad idea, but is fraught with landmines. In the end, this choice is less about technology and more about adoption and ecosystem momentum. Vendor and professional investments in tools, training, and skill sets surrounding Terraform is a formidable moat, and it cannot be easily replicated. Tools that would win over Terraform would have to win adoption, and achieving adoption means delivering all the enterprise-grade features and support that Terraform users currently enjoy. Chef and Puppet are examples of how this could happen. Both were successful technologies, but they were slow to react to the challenge presented by Terraform. Ultimately, these projects suffered from a legacy mindset and were overtaken by Terraform’s more focused, simple solution.

    Most of the issues with Terraform lie in managing it at scale. When you have many workspaces and templates, it becomes hard to manage; it’s also a challenge that templates cannot be generalized among environments, resulting in a lot of template redundancy. Also, Terraform still needs help handling Day 2 operations and visibility into drift detection. 

    When considering ways to extend Terraform to address a broader set of use cases, you should first consider how well things will interoperate across your environment. If you have multiple clouds, multiple service layers and multiple cloud vendors, this is probably the most important factor. Also, investigate any new technology’s ability to support the things about Terraform that are critical to your Day 2 operations. Things like secrets and state come to mind. You’ll want enough management and monitoring in the new solution without it being a new burden to carry. You should be able to use your existing Terraform files, and you should be able to support all the versions of Terraform that you run. Compliance with governance and audit are key, and the new solution should support Terraform for both your on-premises/air-gapped environments and your cloud environments. Ideally, anything you add to Terraform would be open source, eliminating new complications from cross-vendor lock-in.

     

    Terraform use case 

    Architecture for how 8451 evolved its Terraform deployment

    For all its shortcomings, Terraform remains the best option on the market for DevOps organizations, and there are ways to manage it with fewer headaches and without developers wasting so much time writing glue code or reinventing the wheel over and over again. One way this happens is by integrating Terraform with meta-orchestration tools that allow Terraform to become more flexible in managing environments and workspaces at scale. The open source Cloudify project is one example.

    Yevgeniy Brikman gave a talk two years ago at HashiConf that has aged well. At the time, DevOps was still in the Stone Age. Today, it’s probably in the Bronze Age. Those of us building IaC today are being asked to deploy infrastructure that looks like modern cities, but the tools we have to work with remain relatively primitive. What we’re building takes too long to provision and it looks bespoke and temperamental at best or kludgy and fragile at worst.

    It’s a story repeated over and over: Teams try to build their own, homegrown solution first as a wrapper on top of Terraform. Ultimately, they realize that it’s unsustainable as a lack of engineering resources becomes a bottleneck. We need solutions that augment—not replace—what they’ve already built and what works. That’s almost always Terraform. With Terraform, DevOps organizations get a proven IaC option that’s targeted to the needs of developers, with a substantial ecosystem and market uptake. When considering its shortcomings, it’s best to embrace an evolution strategy, and not start from ground zero.

  • The Automation Continuum

    The Automation Continuum

    The speed of innovation these days is often influenced by the speed of adoption of new and exciting tools, and specifically open source tools.  Open source projects have been growing at an exponential speed over the course of the past few years; however the process for exploring, testing, configuring, and ultimately integrating these in production often times is still quite complex and time consuming.  In many cases, this process is still done manually.  Like with all DevOps processes by automating this, we are then able to adopt new tooling much more quickly, and with less human error in the process.

    The Open Source Revolution

     

    The friction in this process is due, in large part, to the fact that each of these stages from exploration through POC and testing, integration and then management, many times requires the use of very different tools for each stage, on top of a completely different setup and environment.  This means that every time you want to move from exploration to testing, for example, you have to basically rebuild the entire system.  This can become quite frustrating and, as mentioned above, time consuming.

    What if we could streamline this process  and explore tens and even hundreds of projects quickly, thereby enabling us to seamlessly increase our innovation?

    How this could work – the flow:

    1. Exploration: Explore the product without having to install any software at all.  This could be through a click of a button on Github, and seeing the product in action.  This would enable you to play with it without having to download, configure, or set up any machines.

    2. Testing: When we move to trying it out, we want to use the same model as in the exploration phase.  We’d like to try it out also on a SaaS basis, but this time with more control.  By this I mean testing with real clusters & machines, in a more high performance, and production-like environment.

    3. Development: At this stage, we want to be able to test it with our actual stack, and plug it into our project quickly.  Then, eventually at a later stage download it and run it in our own environment.

    What’s Needed

    With a unified tool for all of these stages, the majority of the friction in the process can be diminished.  One way to achieve this is by running the project as a service or in our environment, with an orchestration engine that can basically be used to take us through all these stages.

    By wrapping the entire project into an uber-launcher [which with Cloudify we call it “the widget”] that any open source project can plug into – like an app store or repository, and any user can start using immediately without necessarily having to know how exactly it runs or works.

    The nice thing is that we can eventually take the software from that app catalog or store, since it’s not packaged as a black box but rather as a blueprint or script. We can then fork it and customize it to our needs.  Because of this, we can actually use the same tools through the entire cycle and break the friction completely.

    So what it all boils down to, is the basic principle of combining the power of SaaS and cloud orchestration to avoid complexity of installation, use a script-based model to make the packaging of software generic – but still customizable, and use a cloud abstraction to move environments without having to change recipe.  This is what we call the automation continuum, and we’ve been using to demonstrate how to take the power of any open source project to any cloud.