This content originally appeared on DEV Community and was authored by Anurag Goel
When I joined Stripe in 2011, the company had four full-time engineers. Even then, one of them was focused exclusively on managing our AWS infrastructure. By the time I left in 2016, the engineering organization had grown to 120, and the team that managed AWS to 25. We had one of the strongest engineering teams on the planet, but more than a fifth of it was focused on undifferentiated AWS heavy lifting that our customers didn’t know or care about.
Assuming a typical Bay Area cost-to-company of $200K per engineer, managing AWS likely cost Stripe at least $5 million in 2016. This was in addition to their AWS bill, equity compensation, and the often ignored organizational overhead that increases with every new hire.
Stripe is hardly alone in spending millions of dollars on DevOps each year. According to data published by the U.S. Bureau of Labor Statistics, businesses spent $78 billion on DevOps salaries in 2020. Ironically, this number is greater than global spending on public cloud providers, estimated at $65 billion in 2020.
DevOps engineers cost much more than the cloud providers they manage.
What do we get for $78 billion? Most DevOps time is spent on tasks that are painfully similar across every organization. Nearly every software stack requires the same infrastructure, tooling, and automation to operate reliably and to enable developers to focus on unique business concerns. There are, of course, minor yet important differences across companies, but the decision to build an internal deployment platform is typically made well before these differences emerge, and is often based on what’s fashionable or familiar. As a result, businesses end up with an ever-expanding DevOps footprint to maintain and expand undifferentiated platforms. Sadly, all this effort and expense is irrelevant and invisible to their customers.
Why don’t more companies choose to scale on a platform like Heroku that minimizes the need for DevOps engineers? When it launched in 2007, Heroku provided a uniquely incredible experience for developers building web apps with an up-and-coming framework called Ruby on Rails. In many ways, this power duo of technologies focused on the developer experience helped usher in Web 2.0 and all the innovation that accompanied it. Sadly, after Salesforce acquired Heroku in 2010, the rate of innovation on the platform began to slow, eventually coming to a standstill in recent years. For companies that needed more than a simple web app, Heroku’s feature set was often incomplete. The lack of persistent disks meant tools like Elasticsearch couldn’t run on Heroku; missing private networking was a deal breaker for security-conscious companies. Websockets support came very late, and HTTP/2 didn’t show up at all. In contrast, AWS kept adding new features and products at an incredible pace, ultimately conditioning new companies to skip Heroku and go straight to AWS while resigning themselves to poor developer experience and reduced iteration speed.
Fast-forward to today, and most new applications are being packaged and deployed as containers, often with Kubernetes. Let loose on the world by Google in 2015, it has quickly replaced VMs as the target management layer for infrastructure, promising portability and automation for containerized workloads. Large corporate marketing budgets have certainly helped, making Kubernetes the tool of choice for DevOps teams managing applications in the cloud. However, in adopting Kubernetes we have traded the mostly well-understood complexity of AWS for a labyrinthian ecosystem that is as convoluted as it is inconsistent in quality. This has forced every company to build their own internal PaaS so application developers can focus on code. Ironically, these custom platforms look more similar than ever, since they're all based on Kubernetes.
This is the $78 billion question: if every internal PaaS looks the same, why waste inordinate amounts of time and money on building and managing these platforms at every company?
Render is the answer to this question: we’re building the modern PaaS every team and company needs to ship better software faster, effectively becoming the ever-expanding devops team for our customers.
Our relentless focus on developer experience is matched only by our resolve to offer customers all the infrastructure flexibility they need without the associated complexity. This has helped us evolve from what started as a passion project in late 2017 to something that looks very different today:
- Tens of thousands of developers and businesses have created more than 300,000 services on Render. In addition to APIs and full stack apps, we now support static sites, cron jobs, managed PostgreSQL databases, background workers, private services, and of course, Docker containers, with more managed services on the way.
- We've launched multiple industry-firsts in the PaaS market, including private networking, persistent storage, managed wildcard SSL, and true resource-based autoscaling, effectively blurring the boundaries between PaaS and IaaS.
- Most importantly, Render has grown to include immensely talented, kind, and diverse humans with stellar backgrounds at companies like Stripe, Twitter, Uber, Lyft, Twitch, LinkedIn, and Heroku. We're always hiring!
As we grow, our goal remains the same: empower developers and businesses to ship better products faster by eliminating DevOps. We’re working to end the tyranny of complexity forced on developers by cloud providers who’d rather sell certifications than focus on developer productivity. We are deprecating antiquated definitions of PaaS and IaaS, combining delightful developer experiences with the flexibility today's applications need. Most importantly, we are asking developers around the world to expect much more from the cloud. Let's get started.
This content originally appeared on DEV Community and was authored by Anurag Goel
Anurag Goel | Sciencx (2021-09-29T16:46:02+00:00) Why Render. Retrieved from https://www.scien.cx/2021/09/29/why-render/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.