EDB Vice President of Performance Engineering, Vibhor Kumar and EDB’s Postgres DevOps Engineer, Doug Ortiz discuss the fully managed PostgreSQL deployment experience.
Earlier this month, we published a blog entitled “Why Developers Love Fully Managed PostgreSQL Databases in the Cloud” in which we spoke to EDB’s own Vice President of Performance Engineering, Vibhor Kumar and EDB’s Postgres DevOps Engineer, Doug Ortiz. Over the course of that conversation they shared why, when your business has made the decision to go to the cloud, fully managed PostgreSQL—in which administration of the database is the responsibility of the provider, so companies don’t have to concern themselves with actually maintaining the database infrastructure—is the best option for developers
Now, we want to dig a little deeper, and look at what the move looks like for DevOps, and how fully managed PostgreSQL specifically makes the transition to a new home in the cloud smoother, and less stressful for developers.
When a business moves their databases to fully managed PostgreSQL in the cloud, what is the developer experience?
Vibhor: When moving on-prem Postgres to fully-managed PostgreSQL, the experience will largely depend on the technology that’s being used to execute the process. A transition to fully managed PostgreSQL that also has an option for EDB Postgres Advanced Server (EPAS) is very smooth.
The developer experience is usually a pretty simple one. They might prepare their applications for the process—make sure everything is ready to go—but they won’t have to worry about playing too substantial a role in the tasks of the move itself.
Doug: The main role the developer will play in a given move to the cloud is in the testing phase at the end. Most of the process will deal with moving data and architecture from one technology to another, but it’s testing where developers really come into play.
Can you elaborate on that? If I’m a developer, what am I testing?
Doug: The testing phase is all about making sure that all your applications were moved successfully—not just that they’re in the cloud database, but that they’re running properly. Developers will always go through a series of tests so that they can make sure they have everything they need, and they can quickly make note of anything that’s missing.
Vibhor: The things that developers have to look out for are very minor. Maybe there’s a new connection string, or maybe something has been renamed, but otherwise the experience should be relatively seamless. Really, beyond testing, the developer’s role in moving on-prem databases to the cloud is more about adapting to moving from one technology to another, and even that is helped by the fact that PostgreSQL in the cloud allows you to keep using all the tools and solutions you’ve enjoyed before.
How might a lack of integrations with those familiar tools and solutions affect a developer?
Doug: The number of configurations that database administrators will have to do when a business moves to a CSP that doesn’t support their previous architecture or key elements of their technology stack in the way that fully managed PostgreSQL does is very high. More often than not, addressing all these configurations will take time and energy away from what developers actually want to get started on, once the move is complete. You've moved to the cloud specifically to take advantage of all the benefits and flexibility it offers DevOps, but now you're delayed from doing so because your team has to wait on administrative reconfiguration.
Vibhor: If you're working with a cloud provider that limits what integrations and tools developers can use, you’re not only having to adapt to an architecture that could be very different than what you're used to, you’re also rebuilding certain vital workflows, and trying to adapt. You can build workflows with easy clicking, and automation. In short, fully managed PostgreSQL databases in the cloud adapt to you, rather than pressuring you to do that adapting.
After testing is complete, how can developers monitor their applications? What sort of visibility features are possible in fully managed PostgreSQL?
Vibhor: EDB provides a sandbox for developers and database administrators alike. With APIs, you can integrate a wide range of tools and dashboards that will help you monitor, schedule, whatever it may be that you’re interested in visibility-wise. The key thing to understand is that most third party developer tools are compatible with PostgreSQL because most third party developers suppose PostgreSQL. It’s a legacy technology that’s been implemented on such a scale that for a tool to ignore it would be silly.
Last time when we spoke about how major CSPs like Oracle or AWS will try to make it so that their tools only work in their environments—the opposite is true with PostgreSQL. Most tools want to be compatible with PostgreSQL (because of its open source nature and popularity) and PostgreSQL is extremely compatible in return. This is as true of visibility and administration solutions as it is of any other use case solution. And it helps that you can configure all of these easily with a command-line interface (CLI).
Are there any misconceptions about choosing fully managed PostgreSQL once you've decided on moving to the cloud, that you want to address for developers?
Doug: There is a conception that fully managed PostgreSQL databases in the cloud provide less freedom when it comes to designing your architecture than just open source PostgreSQL might. Whether this is a problem for businesses, the answer is pretty nuanced, 'yes and no'. Whether it’s a problem for developers? Rarely.
The ability to build an entirely unique architecture, without constraints, from scratch is mostly something that IT and infrastructure consider. While there are some teams who really value that level of autonomy, the things you sacrifice by doing so—the things that a managed database provides—are the things that ultimately really benefit developers.
Vibhor: If you build your own infrastructure completely from scratch, outages become a major hassle because, rather than just seeing if your database provider is having issues—which they’ll be working to fix—you have to check every single element of your architecture on your own, which makes it much harder to deal with the outage expediently. You don’t have a support team to call, nor updates to rely on. This overworks administrative and IT teams, and makes it harder for them to help developers do their jobs.
Every hour spent trying to figure out what’s wrong, is an hour where your developers can’t do what they need to do.
Doug: And it’s not just dramatic outages. Solutions like EDB’s BigAnimal provide you with a dedicated support team, so that IT isn’t the one fixing every problem, big or small. It frees them up to help empower developers and make sure that their needs are met. In my opinion, any of the minor restrictions one might say a fully managed PostgreSQL database presents are nothing compared to the stress it takes off of developers when they most need support.
Optimizing your move to the cloud with fully managed PostgreSQL
Moving your databases from one provider to another is a daunting task that only becomes more of a chore if—once you reach your destination—your most vital teams aren’t able to return to their routines with ease. For developers, the idea of moving a wealth of applications to a new database environment, only to be waylaid by hours if not days of testing is a headache and a half.
Luckily, fully managed PostgreSQL databases avoid that. With solutions like EDB’s BigAnimal, developers not only have an easy journey to their new home in the cloud, but they’re able to quickly get back to achieving and innovating. The backbone of your business deserves tools and support that empower rather than stymie them.
If you want to learn more about how fully managed PostgreSQL in the cloud revolutionizes the way businesses work, check out EDB’s Ultimate Guide for Moving Your PostgreSQL Database to the Cloud.
If you’d like to experience what EDB’s BigAnimal can offer your developers, request a free trial.