The Startup’s Guide to Platform Engineering
Platform engineering has improved operational efficiency for software teams of all shapes and sizes, but for lean or rapidly scaling teams, building an internal developer platform feels like a herculean task. Platform engineering is a new discipline without much documentation. Platform engineers are hard to come by and harder to hire. Trying to DIY a platform is daunting at best, and even managed services struggle with the “final mile” problem — they’re great for serving the bulk of your business, but fail on the finer details.
With all those obstacles (and a lot of dubious internet hype), you may be wondering if platform engineering is worth the effort or if it’s just another passing tech trend.
In this blog, we’ll take a deeper look into what platform engineering is, explore how internal developer platforms work, and discuss how to build an internal platform that works for you and your team.
What is Platform Engineering?
Plenty of virtual ink (ours included) has been spilled about the rise of platform engineering, but for the sake of clarity let’s define what we mean when we say “platform engineering.”
Platform Engineering comes from (but is not) DevOps
Before we discuss what platform engineering is, let’s take a moment to discuss what it isn’t.
Developer Operations or “DevOps” came into prominence as both a discrete type of engineering, and a philosophy for software development at large, in the late aughts. Prior to the rise of the DevOps functions, developers and IT/operations teams existed as entirely separate entities within an organization. Interdepartmental collaboration was minimal, and the people working to build the software rarely, if ever, interacted with the people managing the infrastructure running it. Conflicting goals and objectives between the two teams created a “fatal level of dysfunction in the industry” which proved especially crippling for organizations as they scaled and moved away from traditional monolithic architectures and toward microservices.
DevOps arose to bridge the gap between software development and operations, enabling a higher degree of collaboration, communication, and automation between the two. DevOps shares many of the same core principles of Agile — short feedback loops, and accelerated delivery — and Continuous Integration and Continuous Delivery (CI/CD) — an emphasis on automation and tooling. DevOps is meant to enable developers and IT professionals alike to do their jobs more quickly and easily while standardizing tooling and deployment within an organization. Ultimately, DevOps exists to increase an organization’s velocity.
However, no two DevOps teams are alike and the function itself has changed dramatically over the past decade, largely due to...
The Cloud and Managing Managed Services
The majority of applications being built today are cloud native, meaning the underlying infrastructure and processes surrounding that infrastructure look very different now than when DevOps first emerged.
As cloud adoption has transformed from hot new trend to industry norm, the tooling surrounding cloud computing has shifted and evolved. Abstraction has always been a driving force in tech, so it’s no surprise that “as a Service” solutions have pulled infrastructure management further and further from the racks of yore.
As a result, DevOps within cloud-native and hybrid organizations has shifted. On premises (on prem) resources and other legacy systems often required bespoke tooling from DevOps teams in an ad hoc capacity. With the cloud, there’s a level of imposed standardization and no lack of extant tooling. Theoretically, anything a developer needs to build and deploy multi-region applications is ready and available from their provider of choice.
But just because there’s a tool that works doesn’t mean it’s easy to use or will play nicely with all the other tools in any given stack. DevOps, then, became less about building new tools as needed and more about wiring extant services together and making them accessible to development teams across an organization.
The nature of the work shifted over time giving rise to…
Modern Platform Teams
Platform engineering builds upon many of the core principles that drive DevOps. There’s still a focus on automation, efficiency, and tooling, but instead of acting as an on-call infrastructure resource, platform engineering teams strive to enable their developers to self-serve via an internal developer platform (IDP).
Instead of internal customers requesting deployments or help with new projects from members of a DevOps team, they can go straight to an internal developer platform that automates deployments and resource allocation. The platform, not the platform engineer, becomes the middleman between developers and infrastructure. This frees platform engineers from serving as a reactive support function and allows them to work in a more proactive, strategic way.
The platform, not the platform engineer, becomes the middleman between developers and infrastructure.
This structure is significantly more horizontally scalable than the DevOps model, as it’s less reliant on individual DevOps engineers picking up the phone or personally managing every project. The self-service nature of internal platforms also enables developers to get what they need as soon as they need it, making platform engineering more operationally efficient for the organization as a whole.
All these benefits, however, come at a cost. Managed services are more expensive than services you manage yourself, and hiring platform engineers is difficult at best and impossible at worst. Not to mention managed services don’t translate well between clouds — meaning you don’t need platform engineers, you need platform engineers who are experienced with your preferred provider. Assuming you have a preferred provider, that is. If you have multiple cloud providers you’ll need significantly more advanced DIY work with complicated orchestration technologies like Kubernetes.
For enterprise-level teams, attracting the right talent and hiring a robust platform team may be a non-issue. But for smaller organizations, startups, and scale ups, hiring a platform team is a major undertaking that may not be possible due to time or resource constraints. Ironic, given smaller teams stand to benefit most from an IDP’s self-service and high velocity.
What is an Internal Developer Platform?
An internal developer platform is a resource developers within a single organization can use to self-serve their infrastructure needs. What the platform does or how it’s built will vary from organization to organization, but the goal is consistent: provide developers with all the tools they need to get their applications to their users.
IDPs are not infrastructure, they’re a layer above infrastructure.
What an Internal Developer Platform Does
Platform engineering is a new discipline, meaning there aren’t many hard and fast rules about what an internal developer platform needs to be or do in order to be considered an “internal developer platform.” We do know, however, that platform engineering exists to increase engineering efficiency and to make infrastructure more manageable and accessible. With that in mind, we can narrow the scope of internal developer platforms to a few key functions:
Infrastructure Orchestration
User demand is not static, and for particularly spiky workloads it’s critical that the right resources are available at the right time and not a millisecond more. Application resources need to scale both for cost and performance reasons, and that scaling needs to be automated in order for our hypothetical platform to be truly self-service. Ideally, the platform should also handle things like load balancing and vertical scaling (to continuously rightsize cores and memory needed for each deployment). It could even abstract away cores and memory entirely so applications “just run” with no need for internal users to even think about resources.
At a higher level, teams and companies may want crosscutting policies applied automatically. For example, “all prod deployments must have at least 5 replicas” or “all deployments should include EU geo-fenced versions.” Individual developers self-serving off the platform shouldn’t need to think about rules like that, but those rules should be visible, unobtrusive, and consistently applied.
Simplified, Standardized Deployments
Deployment is where software most commonly meets infrastructure, so it’s safe to assume an internal developer platform needs to provide a simple way for software engineers to select where they need their app (for high-level business and compliance reasons) to run and deploy accordingly. Every team using the platform should be able to follow the same handful of steps and have their application delivered to their users with little fuss. Ideally the platform could also integrate with CI/CD tools for truly automated deployment pipelines.
Automated Disaster Recovery
Outages happen, and when they do the ideal internal developer platform needs to be able to compensate so engineers don’t have to. Continuously optimizing and rescheduling workloads to the next best available resource elevates an internal developer platform from a useful tool to a critical piece of infrastructure in its own right.
Configuration Options
Different applications have different needs, and those needs should managed in a standardized way. Being able to restrict where an application is running, cap resources, manage metadata, and more should be able to happen on a per-application or per-workload basis with the same set of tools and processes. That said, how much or how little control any given developer needs will vary from team to team and there is no standard level of granularity that will work for everyone. Knowing what needs tuning on any deployment is key to developing your platform.
Do I need an Internal Developer Platform?
All of this sounds great, but to a budding startup or growing scale-up there’s still a burning question: do I really need this?
The short answer is “yes, because you’re probably doing some form of platform engineering already."
Every tech company, no matter how big or how small, needs to run their application somewhere. Infrastructure is necessary at all levels, the only thing that changes is the scale and accessibility of that infrastructure. If your organization doesn’t have a dedicated DevOps or platform engineering function, someone (or some service) is stepping up to fill the gap, manage the infrastructure, and deploy the software.
This can be fine while an organization is small, but as it scales the platform gap rears its ugly head. Entry level services have scaling limits. A growing user base requires more resources to support. Technical debt accumulates and compounds. It’s not a matter of “if” an organization needs an infrastructure solution, it’s a matter of when.
Internal developer platforms don’t need to be massive, fully custom, multi-cloud affairs in order to reap the benefits of platform engineering. A platform comprised of ready-made managed services can be just as functional and efficient as a bespoke Kubernetes solution specially crafted by a team of platform engineers.
Luckily, you don’t need a platform engineering team to build an internal developer platform.
In fact, if you do have a platform team they’re best leveraged for the final mile, where they can tailor your platform to your specific business needs, rather than focusing on the basic functionality available off the shelf. Sometimes the wheel needs reinventing, but sometimes it just needs a custom hubcap!
How to build an internal developer platform
There are many ways to skin a cat or, less graphically, there are many ways to build an internal developer platform. Given the title and focus of this blog, the majority of this section will be about the fastest and most cost effective ways to accomplish the core goal of platform engineering: improve shipping velocity. This will be most relevant to startups and scaleups, who are most concerned with speed and headcount, but any organization of any size could use the suggestions below.
You, dear reader, are the expert on your specific business needs, resource pool, and hiring capacity. Feel free to use our insights are you see fit.
Simple: Using Managed Services
Bear with us: everyone should be using some number of managed services for their internal developer platform.
Even if you have enough platform engineers to field an Australian football team, you should still seriously consider using managed services. It will make building your IDP faster, remove a lot of toil, and free your platform team up to focus on the parts of your platform that can’t be bought.
Most managed services are fairly “out of the box,” so the bulk of the work lies in configuring and wiring those services together to meet your needs. For example, combining a load balancer with a cloud infrastructure service and relational database then putting it all behind an API gateway would accomplish the goal of automating some infrastructure management and making it more accessible.
Theoretically, you could combine dozens of managed services and effectively create a complex internal developer platform with multi-region disaster recovery.
However, much like the diagram above, this solution comes with many asterisks.
Managed services are low-level, meaning it’s easy to get started but will require a lot of micromanaging to maintain. Configuring load balancers, figuring out where to run a database server or cluster, making it work with your business needs — all the final mile problems that make a platform useful for your specific business rear their ugly head. The more complex your app, the longer that final “mile” becomes.
The very nature of a managed service platform is also going to differ from something that’s 100% DIY. Managed services are automated building blocks, so the emphasis is going to skew more toward the automation of individual components rather than in making the sum of those components simple and self service. Plenty of managed services can be accessed via user-friendly APIs (or GUIs) but there is going to be less cohesion between them. Developers will likely be left with multiple points of interaction and lot of underlying maintenance.
This isn’t to say you can’t make a functional IDP out of managed services, only that it helps to be realistic about how much work putting all the pieces together will be, both initially and on an ongoing basis. You may also need some infrastructure knowhow and a willingness to continually tweak and manage your platform.
Overall, this is a viable option for smaller teams, especially if your deployments are only single region and don’t require automated DR.
Scaling Up: Using Infrastructure as Code
Infrastructure as Code (IaC) is the process of provisioning and managing infrastructure defined through code, as opposed to manual processes. Instead of having to interact with resources directly and individually, IaC solutions allow users to define infrastructure changes with code which the IaC tool then executes across resources on the users’ behalf. IaC tools can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.
Once resources are defined within configuration files it’s possible to create consistent automated workflows to provision and manage infrastructure, which is great, however standing up IaC tools is less straightforward. IaC is extremely low level. Without tooling to hide the complexity, it requires app-level developers to deal with provisioning and infrastructure which can undermine the core principles of an IDP.
Tools like Terraform, Ansible, and Pulumi can be excellent options for teams with small applications or on prem resources. They’re powerful solutions with manageable learning curves, making them relatively accessible options. However IaC becomes considerably more complex at scale, usually requiring at least one engineer with infrastructure experience to build and manage.
This isn’t (inherently) a bad thing, just something to keep in mind if your organization is expecting to grow, add new regions, or adopt a multi-cloud strategy.
Enterprise: Using a Platform Team
For large organizations juggling on prem resources, multiple regions, multiple cloud providers, edge deployments, or particularly complex architectures, an internal platform will likely need to be built from the ground up using complicated orchestration systems in conjunction with managed services. In those instances, it may be wise to build a platform team to ensure all your needs are met.
This option is easily the most expensive and time consuming, but (assuming you can hire the right engineers) it all but guarantees a custom solution that does everything you need it to do with the added benefit of ongoing, in-house support from the people who built it.
What your platform team builds will depend entirely on who you hire and what you need. The tools they use might be Kubernetes, or a host of GCP services, or even Seaplane! It’s all entirely up to your organization and your team.
Simple, Scaling, Enterprise: Using Seaplane
For this build we’re obviously biased, but we’re also the experts!
We started Seaplane because we believe a user-centric control plane is the missing piece that makes the cloud accessible to your average developer, so our control plane functions a lot like a multi-cloud, multi-region internal developer platform with automated rescheduling, autoscaling, routing, and load balancing.
Right now our focus is on containerized workloads and the compute piece of the platform, but we’re working with early users to expand to the data layer as well. Stay tuned for that!
Many of our core features are informed by the principles of platform engineering, chiefly: increased velocity, an emphasis on easy deployment, increased availability, and automated disaster recovery. Seaplane is also extremely easy to use, even without infrastructure expertise, making it ideal for developers who just want to ship their apps without hiring a platform team.
You can a look at our documentation for details, or contact us below for early access.
At the end of the day, it’s up to you to decide if platform engineering is right for you, your team, and your business. While we think most organizations would benefit from using an internal developer platform, at the very least we hope we gave you a solid enough foundation to make an informed decision either way. Happy landings!
