--- title: "An Internal PaaS to Manage AWS: Don’t Do It!" id: "3636" type: "post" slug: "an-internal-paas-to-manage-aws-dont-do-it" published_at: "2019-08-28T13:16:35+00:00" modified_at: "2022-02-03T20:13:51+00:00" url: "https://www.lastweekinaws.com/blog/an-internal-paas-to-manage-aws-dont-do-it/" markdown_url: "https://www.lastweekinaws.com/blog/an-internal-paas-to-manage-aws-dont-do-it.md" excerpt: "Atlassian built an internal PaaS to manage AWS. This is usually a bad idea, and you're not Atlassian." taxonomy_category: - "Uncategorized" --- Recently, I linked to [Atlassian’s internal PaaS](https://blog.developer.atlassian.com/why-atlassian-uses-an-internal-paas-to-regulate-aws-access/) that they use to regulate access to AWS and described it as an anti-pattern, or an overly and unnecessarily complicated solution that usually makes things worse. I got a lot of feedback on that link—all of it phrased almost exactly the same way: *Can you explain why that’s an anti-pattern? I’m not saying you’re wrong. Please don’t hit me*. The concerning part is that apparently folks think that I’m enough of a jerk that I’d unleash the Legions of Mockery for asking a sincere question. But I’ll leave that for another day. The question is excellent and I haven’t seen it tackled publicly yet—so let’s do it! For those too lazy to click the link above (mice are annoying; I feel you), Atlassian has an internal system called Micros. It’s a platform as a service that they use to wrap AWS services for their engineers. It obscures away underlying AWS services and contexts such as databases, Availability Zone mappings, and direct calls to specific services. The idea is seductive, the story compelling, and the direction generally wrong. Here’s why. # AWS is confusing, this sounds like it simplifies it, what’s the problem? In the blog post itself, Atlassian mentions many of the problems that come with their PaaS in a series of disclaimers. “Teams can open a ticket if they need to bypass it!” Because everyone loves communicating via tickets! “There’s no mandate to actually use this thing!” “We sometimes bend the rules anyway!” The list goes on. To their credit, they explicitly call out a number of trade-offs: it’s harder to experiment with some native AWS services, it forces compromise in the decision of *awesome native service feature* vs. *staying within the supported Golden Path*, and it breaks a bunch of third-party tools. They have mitigation for most of these, but the overall pattern is what I object to. The painful part about this approach is that it forces you to make a number of tradeoffs, you don’t get the benefits of global advancement in your cloud platform of choice, and it introduces abstractions at a part of the stack that’s prone to errors when launching new services. More insidiously, you’re learning to work with an internal platform rather than AWS itself—which means that the skills you learn working within Atlassian are much less likely to be directly transferable to another company when it comes time for the next stage of your career. It’s also not a new pattern. Yelp tried this before with [PaaSTA](https://engineeringblog.yelp.com/2015/11/introducing-paasta-an-open-platform-as-a-service.html) , an internal platform that tried to do much the same thing, albeit with containers and Mesos. Yelp, however, took it a step further and [open sourced it](https://github.com/Yelp/paasta/) . But despite its tasty name, PaaSTA largely remains a single-shop platform that’s failed to find meaningful adoption. # Hang on, doesn’t everything you’re saying here apply to Terraform? It absolutely does—except! Except [Terraform](https://www.screaminginthecloud.com/episodes/episode-67-infrastructure-as-code-with-terraform-and-mitchell-hashimoto) is an open source product that’s run in many shops. Except Terraform tracks AWS launches very closely and often beats CloudFormation, for whom a search party is currently being assembled. Except that as of [the last Last Week in AWS reader survey](https://www.lastyearinaws.com/) , Terraform and CloudFormation are deployed in equal numbers. # So did Atlassian screw up here? Not at all. Their post is a thoughtful, nuanced piece that’s aware of the decisions they’re making and the cost of those decisions. I take no issue with the path they’re treading. My concern is that some five-person Twitter for Pets startup is going to read that post and start building their own version of it—which is the precise wrong direction. Further, they call out that their choices tie them tightly to AWS but that, strategically, they don’t see this as a particular problem—which is absolutely the right call (pick one provider and go all in!). Atlassian did good work with this. But you’re not Atlassian. Choose another path. by Corey Quinn Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure. ## More Posts from Corey [Back to the Blog](https://www.lastweekinaws.com/blog/) [https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) ### [Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […] [Read More about Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) ### [Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […] [Read More about Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ### [S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […] [Read More about S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ## Get the newsletter! Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark. "*" indicates required fields