![]() ![]() Since Aurora is a managed service, you can get up and running faster by remaining laser-focused on your data models and system architecture. It’s a drop-in replacement for either MySQL or PostgreSQL. It’s not a “MySQL-like database” – it delivers full compatibility. Amazon Aurora: key featuresįrom a technical perspective, Aurora is quite impressive. With a highly scalable distributed storage subsystem, Aurora handles automatically some of the more challenging aspects of managing a database platform, such as storage growth, database clustering, and database replication. “Compatible with” gives you the flexibility of exposing it as either a MySQL or PostgreSQL database to your platform, products, and services.Īrchitecturally, Aurora inherits the value of RDS and adds in the benefit of separated storage and compute.“Relational database engine” means you still reap technical benefits such as speed, reliability, and ACID compliance.“Fully managed” means you spend less time running IT and more time investing in your IP.Managing microdatabases with Amazon AuroraĪmazon Aurora (Aurora) is a fully managed relational database engine that’s compatible with MySQL and PostgreSQL. That frees them up to solve real data problems.ĪWS provides an option that can achieve both (no licensing, fully managed): Amazon Aurora PostgreSQL. Moving to managed database platforms can also help re-allocate budget by taking DevOps tasks off of your DBA’s backlog. Once there, you can apply the savings from decreased licensing costs towards further modernizing your data footprint into microdatabases. You can start by migrating your data store into PostgreSQL. ![]() Let’s look at how we’d transition off of a monolithic SQL Server. This unlocks budget you can apply towards continued evolution. Instead, use a more agile and incremental approach (described below) to reduce licensing costs up front. Rather than having a monolithic schema that all services use, isolate your data via table, schema, or database per-service. The amount of database platforms you use in combination doesn’t matter nearly as much as the way you use them. That ‘s because you make design decisions within a single service – not the entire platform. Doing so allows for much greater flexibility in changing technologies for your data store. We can modernize data stores in the same way. We’ve modernized monolithic platforms by breaking them down with a microservices architecture. It doesn’t address this inflexibility.Įnter microdatabases. Moving from one platform to another only solves for cost. It’s that the system architecture is so inflexible that swapping database technologies has become cost prohibitive. The problem isn’t that licensing has become cost-prohibitive. To start, let’s address the actual root cause. But we couldn’t afford the expense of modernizing our data tier. We couldn’t afford to stay on our database platform. Due to mounting pressure from our competition, our pricing model could no longer support the licensing costs. ![]() ![]() We knew we needed to diversify our data strategy. I managed a global software product running on a massive commercial database. In the not so distant past, I found myself in this very predicament – one that many of my current clients share in common. Inflexible architecture is limiting your options This is despite the ever-growing list of benefits in moving away from commercial database engines. In our experience, customers often focus on modernizing front-end and back-end compute systems and focus less on their back-end data stores. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |