DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. 5 Things Nobody Tells You About DevOps

5 Things Nobody Tells You About DevOps

There are some harsh truths to employing devops. We have a look at them in this article.

Yaniv Yehuda user avatar by
Yaniv Yehuda
·
May. 31, 16 · Opinion
Like (5)
Save
Tweet
Share
8.99K Views

Join the DZone community and get the full member experience.

Join For Free

bas plum had a great article yesterday on devops.com where he lists the five harsh truths about devops. i will summarize his 5 points and add one of my own.

  1. there’s no “that’s not my job” in devops
    plum points out that with devops, the development team is responsible for writing the automated scripts that deploy the application. that used to be manual work done by someone in operations. just as in manufacturing, automation will eliminate jobs. typically, that system administrator can be retrained to work in development writing deployment scripts, but programming is a different skill from restoring databases. if you can’t adapt, it’s time to update that resume.
  2. not everything should be automated
    plus argues that yes, devops can be made to work on any platform, including the mainframe. no, it’s not confined to projects using agile. you don’t have to use ruby or php, it’ll work for fortran applications too, but be realistic. transforming an application to take advantage of devops is expensive. you should not invest in something that is slated for sunset, or has only one release per year to fix some minor bugs. legacy systems are considered legacy for a reason. focus on the top 20 percent of your portfolio instead.
  3. developers will need to get their hands dirty
    some developers like to do one thing, and one thing only: write code. grudgingly, they’ll test, they’ll attend team meetings if they have to, and, if tortured, they’ll write documentation. but forget about getting them to create the installation scripts. according to plum, “that mindset is not going to fly in a devops world. developers need to think about how the application will run as a nonfunctional requirement, and treat it with the same level of importance as security, performance and data privacy. unless they feel ownership of the installation process, monitoring the environment and collecting end-user feedback, you have not really implemented devops.”
  4. operations can no longer be ticket-driven
    usually, the operations team doesn’t get involved until someone from the development side opens a ticket for deployment. that’s too late for any kind of meaningful integration. the answer according to plum is not to open a ticket three months earlier; tickets are meant to be assigned, worked and closed within a short period of time. the type of collaboration needed between development and operations is far more complicated, and should be treated like it’s a project. that’s really difficult for most operations organizations. it’s not part of their culture, and they’re not staffed for that.
  5. your process is really, really bad
    plum’s last point is that as soon as you start automating your software delivery process, you’ll find out exactly how inefficient it really is: duplicate reviews, inconsistent forms, competing standards, etc. when you take away the people layer, you can’t hide the crazy anymore. you don’t want to take what you have today and force it into an automation tool. you will need to standardize before you optimize, and optimize before you automate. that means a lot of different towers will need to cooperate — something that won’t happen unless there is an outside party driving the cooperation with a big stick.
  6. you can’t skip the database
    the point i would like to add is that while leading organizations are increasingly adopting devops, they often find it challenging to support database release automation, while ensuring database updates are delivered rapidly and securely. these challenges have led a number of fortune 500 companies to database downtime caused by out-of-process updates, code overrides, and other database glitches. the database must be treated as a first class citizen in the devops process or it can become the weakest link which hold back the entire development lifecycle.

for more about devops for database download our free ebook: in database automation we trust.

DevOps Database

Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Real-Time Stream Processing With Hazelcast and StreamNative
  • Key Considerations When Implementing Virtual Kubernetes Clusters
  • The Importance of Delegation in Management Teams
  • Enabling DB Migrations Using Kubernetes Init

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: