1. The Future of The DBA
DevOps, the Cloud Paradigm, & the Microsoft Data Platform
Stuart R Ainsworth

2. Agenda 1 2 3 4 1 Describe the typical state of database administration
Define & describe DevOps and the cloud computing paradigm 3
Explore (high-level) the Microsoft Data Platform 4
Discuss the implications for data professionals

3. Assumptions About You 1 2 3 4 2 SQL Server experience
Exposure to database admin & architecture 3
Learning-centered 4
Desire to build modern skills

4. About Me 3 Manage IT for financial services company
Former Data Architect, DBA, developer
AtlantaMDF Chapter Leader
Infrequent blogger:
My career trajectory
Experience with large (well, used to be large) databases (multi-terabyte data warehouses, relational db’s)
Active in the SQL Server community; speaker, chapter leader Tyr to stay abreast of all the new technologies, but….
About 5 years ago, I moved into management, and my career trajectory has shifted more toward understanding people and processes than being a DBA
Focus is on solving business problems regardless of the tools; cant understand depth, but better at breadth.

5. 4 You have brains in your head And SQL Skills to boot
You'll soar to great heights
On the Data Platform too
You're on your own,
And you know what you know,
And YOU are the one
who'll decide where to go.
PASS Summit 2016 Lightning Talk that was well received
Stepped through the data platform and how skills will shift for DBA’s

6. 5
Where Are We?
Typical SQL Server Person

7. Typical SQL Server Person6
Specialized knowledge
May have exposure to other infrastructure or development tools
Usually reports to Operations (not Development)
Often one of the “last stops” in deployment chain
You may encounter “the development DBA”; but in most cases, that hat is worn by production dba’s that do some development OR a application developer that writes SQL OR large organizations.
This is just supposed to give a representation that’s middle of the road

8. Typical SQL Server Person7
Development Skills
Administration Skills
SQL (DDL & DML)
Performance Tuning (Code)
Index Analysis
Data Warehousing
Reporting
Server Configuration
Performance Tuning (Server)
Index Maintenance
Backups and Restores
Security

9. MCSA SQL 2012\2014 8 70-461: Querying Microsoft SQL Server 2012/2014
70-462: Administering Microsoft SQL Server 2012/2014 Databases
70-463: Implementing a Data Warehouse with Microsoft SQL Server 2012/2014

10. What’s coming… 9 Data production is accelerating Data is diversifying
Est .79ZB in 2009
Est 7.9ZB in 2015
Est 35ZB in 2020 (44 times greater than 2009)
Data is diversifying
Relational Data
Big (Size) Data
Fast Data
Dark Data
Lost Data
New Data
It’s overwhelmening
Increase in both size and diversity of data just increases the likelihood that we’ll lose control of the data explosion

11. 10
DevOps
Philosophy, not Methodology

12. A (Very) Brief Overview11
DevOps is focused on delivering quality, faster.
Philosophical approach, not methodological
Automation, infrastructure as code, continuous deployment
Emphasis on communication; silo reduction
Born out of Agile, several innovators contributing
Patrick Debois & Andrew Clay Shafer – Agile Infrastructure (Agile 08)
John Allspaw & Paul Hammond – 10+ Deploys Per Day (Velocity 09)
Gene Kim, Kevin Behr, & George Spafford – The Phoenix Project
Philosophy in that there are a set of general guidelines, but no specific “how to” manual. Embraces several different methods (Scrum, Safe, Kanban), but none are required.

13. The Phoenix Project 12
In simplified terms, this is the way most deployments SHOULD work.
However, the more complicated the deployment (the more moving parts, more types), the more likely it is that the deployment will fail, and then you face the dreaded ROLLBACK
For example, say you have a .NET web app that connects to a database; when you make a change to the app (system engineers), you also need to deploy some new stored procedures (DBA’s)
The simpler the deployment, the less likely the need to rollback.

14. The Phoenix Project 13 AMPLIFY – make louder
Get Feedback into the hands of development as soon as possible, in form of stated issues.
AUTOMATE YOUR FEEDBACK SYSTEMS AS MUCH AS POSSIBLE.
Data is Data; start looking at feedback as a data challenge to solve.
Note that the arrows are circular; if you can speed up the deployment time, and the feedback time, it becomes much easier to move forward and not rollback.

15. The Phoenix Project 14
IF you get your deployment and feedback cycles tight, and eliminate rollbacks, that gives you the opportunity to take risks and expirmenet.
Get new features into the hands of beta customers, faster, for example
If your application monitoring systems tell you it’s breaking, then you can quickly deploy a fix.

16. Key Takeaways 15 DevOps is rooted in a sense of continuous improvement
People over tools
Reduce silos by focusing on shared goals, not technology 1.
2. Lots of great tools: Atlassian products, Slack, HipChat, VictorOps, PagerDuty
3. Tool specialization can create silos; for example, SQL Server DBA’s don’t often hang out with Oracle DBA’s.
But end users just want data; they don’t care about the underlying differences.
DevOps is about figuring out innovative ways to create value, faster; what we need is a paradigm shift.

17. 16
The Cloud Paradigm
Infrastructure, Platform, Software

18. What do we mean by “The Cloud”?17
Trendy marketing term?
Network hosting?
Internet connected services?
Distributed, scalable, shared computing resources?

19. Product-Focused Paradigm18
Product-focused paradigm; different teams specialize in different products, even when products have similar functionality

20. Cloud Paradigm 19 Applications Data Runtime Middleware O/S
Virtualization
Servers
Storage
Networking
Cloud Paradigm looks at function, not products
Each level on the stack is dependent on the previous one, but each level is opaque.
IE, the OS you chooses shouldn’t care about the underlying Virtual configurations (VMWare vs VirtualBox vs Hyper-V).

21. Cloud Paradigm 20
This is where it gets interesting; you can then begin to group elements in the stack, and consume the management of those groups.
On-prem, you manage it all
Or you could consume infrastructure as a service from someone else….
Your clients that are running your software don’t manage anything; they just bring their input (e.g., Power BI, Google Docs, etc) - SaaS

22. Cloud Paradigm 21

23. Cloud Paradigm 22

24. Limoncelli, Chalup, Hogan23
Limoncelli, Chalup, Hogan

25. Ideal System Architecture24
Scalable
Resilient to Failure (Redundant)
Service-Oriented Architecture
Automated Monitoring, Configuration and Build
“Infrastructure As Code”

26. Ideal Release Process 25 Completely Automatic
Code checked in -> new build
Unit & regression testing
User acceptance testing
Continuous Integration
Dependent on “infrastructure as code”
Micro-releases (100 deployments per day)
No rollbacks
Micro-releases, and no rollbacks. Sounds familiar, I hope

27. Ideal Operations 26 Automatic instrumentation (Logging)
Long Term Storage
Predictive Analytics
Automatic Error Logging & Alerting
Respond to Every Error
On-call Rotation includes Developers
Automatic Scaling
Scale Up
Scale Down
“Zero Maintenance”
Automatic instrumentation

28. Ideal Data Architecture28
Consistent
SQL Server Relational Engine
Hadoop
Consistency - all nodes are guaranteed to see same data
Availability – every request receives feedback for success/failure
Partition Tolerant – system operates despite loss of part of system
At any one time, any two attributes are achievable in combination, but not all three at the same time.
Available
Cassandra
Partition Tolerant
CAP Principle (Gilbert & Lynch)

29. Microsoft Data Platform29
Microsoft Data Platform
Diversity in Data

30. Microsoft Data Platform30
Conceptual; think function instead of tools

31. Microsoft Data Platform31
On Prem tools include Excel for Ad Hoc queries, DataZen for advanced reporting, SQL Server, with SSIS and Analysis Services

32. Microsoft Data Platform32
Same basic function in Azure, just slightly different tools. While the interfaces and UI may be different, the fucntions are similar to their on-prem counterparts.

33. Impact on Careers 33 Future Prognostications
So what does this all mean?
Fun part about guessing about the future is that I don’t have to demonstrate it, I just have to read the tea leaves and get enough things right to look like a genius.

34. Current Trends 35
Companies are recognizing the value of different kinds of data, and an increased need for analytics.
Adoption of Big Data technologies is on the rise
Data Science jobs are increasing
The Internet (or Fog) of Things is coming.
Operational methodologies like Agile and DevOps are pushing companies toward the Cloud Paradigm.

35. Current Trends 36
The Cloud Paradigm with its separation of duties is causing companies to realign resources.
Infrastructure Teams
Platform Teams
Software Teams
Operational technologies (virtualization, scripting) are allowing organizations to scale out computing resources with fewer human resources.

36. Cloud Paradigm 34 SQL SERVER Applications Data Runtime Middleware O/S
SOFTWARE
Applications
Data
Runtime
Middleware
O/S
Virtualization
Servers
Storage
Networking
SQL SERVER
PLATFORM
INFRA- STRUCTURE
Note that
SQL Server bridges two different service buckets; platform and software
Runtime: the server functions, ie., true administrative tasks like security and backups
Data: the database schemas, data, etc. Data is built on the Runtime.

37. My Predictions 37
Increased segregation between Development and Administration roles.
Number of development jobs will increase
Diversity of data platform.
Need for integration.
Data mining and analysis skills.
Number of administrative jobs will decrease
Infrastructure as code, scripting, virtualization
Product specific specialists for initial configuration

38. What does this mean for YOU?38
Choose your path: Development or Administration
Developers have opportunities for breadth:
Big Data (Hadoop, HDInsight)
Data Science (Statistics, R)
Visualizations (Reporting, Power BI)
Administrators have opportunities for depth:
Always On
Infrastructure & Platform impacts
Scripting & configurations

39. MCSA SQL 2016 39 Querying Data with Transact-SQL
Developing SQL Databases
Administering a SQL Database Infrastructure
Provisioning SQL Databases
Implementing a SQL Data Warehouse
Developing SQL Models

40. 40

41. Contact Me Stuart R. Ainsworth Twitter: @codegumbo41
Stuart R. Ainsworth
Blog:
Slides available:

42. Continuous Improvement for your career
Be Good at Getting Better