Why “the way we have always done it” is not always better
Based on the Stonebraker keynote at Postgres Build 2021
How you used to do it
Databases are really nothing new. If you consider that Relational Database Theory stems from the early 1970s and it was voted to be the way forward at the Great Debate in 1974, there already was a whole history of databases before that event. In effect, computers were largely invented to manage databases; most everything else is icing on the cake.
A really long time ago
In some of the earlier stages, applications and databases actually lived close together in harmony on one single computer. This understanding of host-based computing, either on large mainframe computers or on these new-fashioned UNIX systems, has long dominated the application landscape.
You would just end up deploying everything necessary in one giant operation on one giant computer and have people share all of that goodness. These machines tend to—and, believe me, many still do—live in well managed (cold and dry) and secured rooms, in which you only wanted to be physically for as little time as possible.
You hear a lot of talk about "pets versus cattle" in IT management; these days. This was not just your favorite pet; it needed a whole lot of TLC to keep it shipshape. All in all an expensive undertaking, but the value was undeniably there.
Until recently
This all changed when concepts like backend, middle tier, and frontend were introduced. Not just physically, but also logically. Applications would no longer run on the (database) server, but inside application servers. Folks would use your application either through a dedicated program or, as it is often the case today, your favourite web browser.
Now…
With regards to cloud, cloud adoption or cloud journey, you hear about companies that are dashing to adopt cloud. They are serious and "quite far along" according to feedback.
They are…until the point where you start asking questions about their databases and the strategy to get them to the cloud.
Moving applications to the cloud might be easy—well, I should say, easier—but moving databases to the cloud is hard(er). Among the wealth of applications, there are distinctions to be made. Applications that work in the area of decision support are often easier to move than applications that work on more transactional data. Often, the reason is that transactional applications tend to be more broadly integrated in application infrastructures either inside or across organisations.
How you will do it
Here we get to the interesting bit. As Turing Award winner Dr. Michael Stonebraker said in his Postgres Build 2021 keynote: "You are going to move to the cloud."
Not just bits and pieces, but hook, line, and sinker. Not just your applications, but your databases as well. Your databases will move to the cloud in order to accompany your applications that might already be there. It might not be a rose-scented and moonlit process, but you will get out of this legacy constraint of on-premises installations.
What you will gain
As with everything, you do not engage in these kinds of activities without gaining a clear advantage. There are two that I want to highlight here.
Cost
There are two elements in the cloud cost debate:
- Your cost
- The Cloud Service Provider (CSP) profit
A. Your cost
To get a clear overview of how much you might actually save when you arrive at your final destination in the cloud, you need to consider all the elements of cost. It is a bit like leasing a car. If you just count the variable costs, leasing a car seems much more expensive than just buying and running it. If you consider all the costs, including the secondary or tertiary costs, it might just be that leasing that Volvo might be a smart move.
Cloud computing costs include most everything, not just floor space, cooling, heating, and what have you. There are also many costs that go into general overhead, or hidden in personnel costs that you happen to have anyway. Companies that have completed the first part of their journey to the cloud now find that in the end owning a car and leasing a car are two very different things;to maximize results, they will replace that other car with a leased vehicle as well.
B. Their profit
This entire treatise has a trap—is there ever not a trap?
With a CSP, you want to avoid getting caught in "the race to the bottom," where the provider with the lowest cost is the one that prevails. Regardless of anything, price will be a competitive instrument for CSPs. However, they will want to use more instruments, and it is not even all that creative. Every CSP will try to lure you in and trap you into their specific offering by offering specific services that bring clearly advertised advantages. Sure, we can have an entire discussion right now about vendor lock-in, technology lock-in, or even personnel lock-in, but I will suffice to say: please be wary of the next "Hotel California."
Elasticity
Next to cost, there is another very clear benefit—elasticity.
It is vital for business to not have to wait for longer than absolutely necessary to gain compute capacity, storage capacity, memory capacity, or those things in more abstract representations. Doing that in an on premises capacity is painful. If anything, cloud takes that pain away. By passing along the pain of scaling up and scaling down as your needs fluctuate to the CSP, you can take advantage of the CSP’s vastly larger computer pool. Poof! Worries gone, peace of mind granted.
What about security?
In the beginning of the cloud computing era, there were many, very serious concerns about security. And probably rightfully so. By now, I think everyone is thoroughly aware of the importance of security. Both from a publicity standpoint, where data breaches are very painful indeed, and from an ownership perspective, where ransomware is lurking everywhere. Not to mention all of the other threats to your security.
While it is the CSP's core business to do IT, it may not be your core business. Stonebraker said it best: “It is pretty obvious by now that the cloud is in your future. Chances are cloud security is better than whatever you have on premises.” Being apprehensive about moving to the cloud because of security issues is a thing of the past.
The next big thing
When it comes to databases, most folks these days think of PostgreSQL.
So much so that, when it comes to databases, a large part of the lure that CSP's use to get you to invest in them, is actually some variation of PostgreSQL. After all, PostgreSQL is the de facto platform for (relational) data management today and tomorrow.
At EDB, we believe that PostgreSQL is the logical way forward. We also see why cloud is an absolute must-have for databases. We believe in "free as in freedom," in the sense that a vendor-specific variation of PostgreSQL is actually not the way to go. This is why we came up with the next big thing when it comes to fully managed PostgreSQL in the cloud: BigAnimal. With BigAnimal you can run standard PostgreSQL on your CSP of choice (currently offered on Azure with many more being added in the months to come).
- No lock-in to a specific variation of Postgres
- No lock-in to any specific CSP
- No lock-in, to cloud in general, as BigAnimal will run everywhere you need it to run
Cloud, hybrid cloud, multi-cloud…we have your back when it comes to fully managed PostgreSQL.
Conclusion
Whether we want to admit it or not, we already know that software (and databases are in fact software) runs in the cloud in one form or another. This was the first part of Stonebraker's message.
PostgreSQL is ready. Although PostreSQL was conceived over 30 years ago, it was made for the cloud. EDB is ready—bringing you unparalleled PostgreSQL expertise and vendor-like support. With BigAnimal, we also made the cloud ready for PostgreSQL—running where, when, and how you need it.
Want to learn more? Read Jan Karremans' previous breakdown of Michael Stonebraker's keynote, and check out all of the on-demand sessions from PostgresBuild 2021!