What is Amazon RDS for Aurora?
Who uses Amazon RDS for Aurora?
Amazon RDS for Aurora Integrations
Why developers like Amazon RDS for Aurora?
Here are some stack decisions, common use cases and reviews by companies and developers who chose Amazon RDS for Aurora in their tech stack.
Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.
I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.
For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.
Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.
Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.
Future improvements / technology decisions included:
Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic
As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.
One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.
Over the years we have added a wide variety of different storages to our stack including PostgreSQL (some hosted by Heroku, some by Amazon RDS) for storing relational data, Amazon DynamoDB to store non-relational data like recommendations & user connections, or Redis to hold pre-aggregated data to speed up API endpoints.
Since we started running Postgres ourselves on RDS instead of only using the managed offerings of Heroku, we've gained additional flexibility in scaling our application while reducing costs at the same time.
We are also heavily testing Amazon RDS for Aurora in its Postgres-compatible version and will also give the new release of Aurora Serverless a try!
#SqlDatabaseAsAService #NosqlDatabaseAsAService #Databases #PlatformAsAService
We migrated from Heroku Postgres to Amazon RDS for Aurora not long ago. The driving force behind the migration was the increased performance and cloud tuned PostgreSQL instances. Pricing was also a factor, as RDS delivers more value for the price. We have a staging and production cluster that can be scaled up or down as we need capacity. Snapshots, backups, and maintenance are handled automatically, though the timeframes are configurable. They offer automatic failover, and multi-az replication #StackDecisionsLaunch
We migrated most of our APIs last year from using our self managed Cassandra cluster to a mix of Amazon DynamoDB and Amazon RDS for Aurora. This has reduced the operational overhead for our team and greatly improved the overall reliability of our service. The new dynamic capacity in DynamoDB has been super helpful for handling bursty traffic.
Our team finalized the migration of the systemic structure that previously remained monolithic, now using micro services.
We have adopted as NodeJs services and for some WCF services with Asp.Net Core.
Now each service has its separate lifecycle and with the help of the containers we increase the scalability in 40% of calls. Node.js Docker Amazon EC2 Container Service Amazon RDS for Aurora
We use Amazon RDS for Aurora because we needed a cloud level scalable solution for database management. We wanted to use a modern database engine that's suitable for the cloud era and also benefit from using SQL and a structured database.
We never wanted to manage the DB infrastructure ourselves so our choice was between Aurora and simply RDS. We chose Aurora because of superior performance and the ease of scaling storage and instances.
Amazon RDS for Aurora's features
- High Throughput with Low Jitter
- Push-button Compute Scaling
- Storage Auto-scaling
- Amazon Aurora Replicas
- Instance Monitoring and Repair
- Fault-tolerant and Self-healing Storage
- Automatic, Continuous, Incremental Backups and Point-in-time Restore
- Database Snapshots
- Resource-level Permissions
- Easy Migration
- Monitoring and Metrics