Recently, I linked to Atlassian’s internal PaaS 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, 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. 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 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, 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.
