Engineers today work inside a perpetual good news-bad news dichotomy. On one hand, the tools, infrastructure and capabilities at their disposal give them what an engineer ten years ago would probably consider superpowers: Containerization and virtualization, continuous integration/continuous delivery, microservices and serverless, Kubernetes, and the incredible development of the cloud woven through all of these things.
On the other hand, engineers also have to manage all those things to some degree. And as anyone who has ever had to configure a Kubernetes cluster, or manage Terraform can tell you, that’s the bad news.
From our partners:
Writing code and business logic is only part of an engineer’s job today – they also have to learn how to make their code work in different, and often changing, runtime environments. To get anything working properly in the cloud, an engineer has to work with at least a dozen tools. Complexity is written into the job description.
Unless, of course, you work for one of the cloud giants. Those companies have entire teams dedicated to creating custom infrastructure to automate most of the DevOps work engineers have to do, so they only have to worry about writing and shipping code. It is, after all, what they do best.
Beyond that handful of companies, however, this ability doesn’t exist. For companies with less engineering resources than Facebook or Google, it sets up a fairly existential choice: Adopt an infrastructure platform like Kubernetes and do the hard work of adopting, configuring, operationalizing, and maintaining it, or miss out on the benefits it offers.
Infrastructure-as-Code is here to save the day … kind of
Infrastructure-as-Code (IaC) solutions are now widely accepted as the standard for provisioning and managing cloud infrastructure, and Terraform is widely considered to be the best IaC platform on the market – and it is. Terraform is a very advanced piece of software, and, quite frankly, one of the more amazing innovations of this era of cloud computing.
It’s also extremely complex. It’s infamous for requiring deep infrastructure expertise to manage, so every company using Terraform needs to have an in-house expert who can work through its complications. Whether that’s the steep learning curve for Terraform’s DSL, HashiCorp Configuration Language, managing its notoriously buggy modules, or even performing low-level tasks like managing network CIDR, or modifying route tables, Terraform isn’t easy to learn or maintain.
Opta is a new kind of Infrastructure-as-Code
We developed Opta to help eliminate this complexity. Opta is a new kind of Infrastructure-as-Code framework that lets engineers work with high-level constructs instead of getting lost in low-level cloud configuration. It’s an open source tool we developed after seeing the problems engineering teams dealt with because of infrastructure complexity.
Our goal with Opta is to make it possible for anyone to have automated, secure, scalable infrastructure up and running in 30 minutes. We want to give any engineering team, whether it’s a team of 2 or 200, the same infrastructure advantages that companies like Google or Facebook have, without having to invest in infrastructure or DevOps engineers.
An engineer could set up an autoscaling Docker container that talks to a RDS database through a 10 line config, instead of spending hours figuring out the details of Amazon Virtual Private Cloud, AWS Identity and Access Management, Kubernetes, Elastic Load Balancing, and so on.
Opta has a vast library of modules (like EKS, RDS, DynamoDB, GKE, Cloud SQL, and even third-party services like Datadog) that engineers can compose together to build their ideal infrastructure stack. These modules are designed by infrastructure experts, follow best security practices and are built to be production grade and interoperable.
Opta is built on top of Terraform, and designed so engineers aren’t locked in to our product. Anyone can write custom Terraform or even take the Opta-generated Terraform and work independently.
We built Opta to give engineering teams a framework for a “Build Your Own Infrastructure Stack” that works for everyone, not just DevOps engineers.
Our main goal now is to build a vibrant community of Opta users, so we can learn from each other, build new and better features and hopefully make infrastructure complexity a thing of the past. Feel free to join us on Slack, or check out Opta on Github to learn more.
Guest post by Ankur Dahiya, RunX
Source CNCF
For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!
