Netflix is one of those companies that I find amazing. I was an early subscriber to their mail DVD service, and thought it was amazing how they processed both orders and physical objects with technology. As they pivoted to streaming, I continued to be impressed with their technology growth, from the chaos monkey to their DevOps deployments. They have been an organization often looked to as a model for other technology companies.
I certainly think there are things to learn from Netflix, as they've scaled and build quite a resilient system. They aren't necessarily worth copying, however, as the problem domain they solve is both narrow and also quite different than that many of us work in. If someone can't watch a movie, it's annoying, but they can pick another one. If a customer can't transfer money, communicate with another user in an app, or schedule a ride, it's a bigger deal for other problem domains.
Still, Netflix didn't build this system overnight. They didn't come up with amazing DevOps techniques for building and deploying their software from the beginning. It's been a journey, and they talk about some of the full cycle developer challenges in a recent blog post. This looks at one team's journey across 6 years, from 2012 to this year. The piece is an interesting read, and it's not advocating for their particular approach, but rather trying to explain the value that they received from moving to a DevOps model, where they have a group that must run what they build.
As I try to help customers and clients move to Database DevOps models, I see lots of similarities to what's in this post. As we look to optimize the entire software development life cycle, this requires a changing of roles and closer cooperation between groups. As I look at the evolution of Netflix, using a centralized group to build tools and then ensuring you have a better staffed development team that works to both build and support their software, ensuring clients get the value (or features) they need quickly.
I've worked in orgs that did this in groups, and for the developers to be involved in operations is an eye opening experience. Developers will learn ensure they think about their design and test more because they don't like getting woken up. They listen Operations and learn about the ways in which they can better build a system that works. They start to realize "works" is a feature, perhaps the most important one.
I've also found my role as a DBA can facilitate DevOps. I'm often between development and Operations, with a foot in both camps. I help developers build better tools and techniques to work with databases. I understand the impact on production databases, meaning I can help ensure that deployments are smoother, and we avoid risky changes. We build indexes early, install primary keys, test queries for performance, and more. The DBA is the one of the ways in which DevOps can grow in an organization, if they work with the developers instead of against them.
The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.
NEW SQL Provision: Create, protect, & manage SQL Server database copies for compliant DevOps
Create and manage database copies effortless and keeps compliance central to the process. With SQL Provisions virtual cloning technology, databases can be created in seconds using just MB of storage, enabling business to move faster. Sensitive data can be anonymized or replaced with realistic data to ensure data is protected as it moves between environments. Download your free trial
The industry standard for comparing and deploying SQL Server database schemas
Trusted by 71% of Fortune 100 companies, SQL Compare is the fastest way to compare changes, and create and deploy error-free scripts in minutes. Plus you can easily find and fix errors caused by database differences. Download your free trial
When analyzing security-related challenges, it is important to note that they encompass several distinct but interrelated technologies. In addition, when dealing with data services, it is also necessary to distinguish between the data plane, facilitating access to the underlying content and the management plane, which allows for delegation of administrative tasks. In this article, Marcin Policht explores how these concepts apply to the Azure Cosmos DB offering. More »
More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater?whether it's the healthcare.gov debacle, cardholder data breaches, or missing the boat with Big Data in the cloud. Get your copy from Amazon today.
Yesterday's Question of the Day
(by Steve Jones):
What is returned by this code?
DECLARE @x VARCHAR = '777';
This code returns 7. Why?
The declaration of this variable as a varchar without a length, is a varchar(1). If you CAST or CONVERT to varchar without a length, then 30 characters are used.
Note: Declaring a varchar without a length is a bad habit, as noted in the first reference below.
Ref: Bad habits to kick : declaring VARCHAR without (length) - click here
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.