Database Infrastructure for Revenue Growth
Database Infrastructure for Revenue Growth
Little things can add up to big expenses or big savings. Which will it be?
Join the DZone community and get the full member experience.Join For Free
Matt began by sharing the impact of small things that impact revenue. Small, easy things are often overlooked and taken for granted like databases with no passwords, outages caused by untested changes, and automation of bad configuration changes. Small things have caused outages at Facebook, Google Cloud, Alibaba, AWS. If it can happen to these companies, it can happen to you.
Security is a huge issue as breaches continue to grow. During just two weeks in March, we saw breaches to Google Cloud storage, a Facebook outage, the Gearbest database leak, two billion unencrypted records leaked, a massive leak exposing 809 million email addresses. There have been a record number of breaches in 2019 with 1,903 incidents already through May. More than any other year. Insider mistakes are the leading cause of these breaches.
User expectations continue to grow. Consumers in their personal and business lives expect apps to be secure, responsive, and available 24/7. Outages or downtime are unacceptable. Losing control of personal data is unacceptable.
Impressions are made in three seconds or less. If someone accessing your app for the first time has a bad experience, they will not come back. Regular customers will not tolerate anything less than a simple and seamless user experience.
All the while, the businesses behind these apps are looking for developers, operations and others to provide more features, more quickly, for less money while keeping all data secure.
Data control, sovereignty, and security have moved to the front burner with GDPR and the daily reports of data breaches and leaks. C-level executives realize data is their most critical asset. Vendors who lose control of your data is just as bad as you losing control of your data.
Other concerns include too many choices and changes, licensing changes, different cloud and (X)aaS options. The cost of making poor choices adds up. Vendors are feuding with cloud providers as they provide more services and this breeds more confusion for enterprises that would like to ditch proprietary databases, but they're unsure of their best options.
They are actively avoiding vendor lock-in so as not to feel the burn from big proprietary vendors. A large portion of the community is employing a multi-vendor database strategy. A multi-cloud strategy is real and growing. Cloud outages are driving concerns as are costs.
Cloud native is a must — run anywhere, any time. Platform portability is huge. More than 25 percent of companies are using Docker/K8s for production workloads. Cloud native methodologies tools and frameworks are changing very fast.
Matt wanted to dispell several myths:
- There is no single database that does it all
- There is no AI, automation, or tool that can handle all database-related needs. For the time being, all databases will need some tuning from a human
- You cannot just blindly copy what bigger companies have done
His advice is to build resilient scalable systems, and plan for them to fail. Automation is great unless you replicate and automate bad things. Databases and their workloads need to change at the same pace, or faster than your application.
Maximize availability by making sure you have automation setup to recover from an outage. The faster you recover, the better you will be and back to making money. Don’t blindly believe what the vendors tell you - test and conduct proofs or concept at scale. There is a lot of great technology (cloud, vendor provider, XaaS) but you have to configure, tune, and test. Build resilient and fault-tolerant applications and systems from the beginning. Set your application up to recover from failure
Ask the question, "What happens when your data center or your provider’s datacenter fails?" If you cannot answer this question you will have a bad and expensive learning experience.
How to exceed user expectations:
- Test and review performance every few months
- Understand the growth patterns of the application and user base
- Know when your most critical days are, understand workflows and their impact on systems
- Build flexible systems that allow you to add database nodes, slaves, or other components to scale up and down to meet the demands of the application
- The best time to solve a slowdown in performance is before it happens
- Understand that milliseconds add up, especially at scale (quick is relative)
- Upfront design is critical, sometimes a bad design locks you into poor performance down the road
- Have the tracking, monitoring, and visualization tools set up before an issue arises
Security best practices:
- Review your database security policies regularly
- Test and audit regularly
- Encrypt and mask data, especially PII
- Restrict direct access to the database, limit this to the absolute need
- Patch your database
How to do it without breaking the bank:
- Don’t rely on just bigger instances or hardware. This is costly and will lead down a very expensive road.
- Regular tuning and scrubbing of databases will reduce costs
- Automate not only the operational tasks, but load testing, and test basic things regularly
- Use the best database and tools for the job
Opinions expressed by DZone contributors are their own.