Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Zakia Bouachraoui, Liz McMillan, Pat Romanski, Elizabeth White

Related Topics: @DevOpsSummit

@DevOpsSummit: Blog Post

Keys to Production Readiness By @Papa_Fire | @DevOpsSummit [#DevOps]

With a bit of wizardry from Chef, anyone can create a pretty reliable replica of the production environment on demand

Data Quantity, Quality & Frequency: Keys to Production Readiness

Despite the fact that majority of developers firmly believe that "it worked on my laptop" is a poor excuse for production failures, most don't truly understand why it is virtually impossible to make your development environment representative of production.

When asked, the primary reason for the production/development difference everyone mentions is technology stack spec/configuration differences. While it's true, thanks to the black magic of Cloud (capitalization intended) with a bit of wizardry from Chef, anyone can create a pretty reliable replica of the production environment on demand. The actual main issue with reliable production mirroring is complex, but can be described in one word - data.

Quantity of Data
Most of the time developers don't have the full dataset to work with in their development environment. For example, testing an application against a 10 row table vs a 10,000,000 one will likely produce significantly different results. As a most basic example, N+1 problem will not be noticeable on the former, but will bring your production to its knees with the latter. Even if a developer decides to be diligent and attempt to re-create the full production data store into a personal development environment, the data will be out of sync as soon as the import is finished. With developer's luck, in accordance with Murphy's Law, it's the 10,000,001st record that will be the straw that breaks the back of your application in production.

Quality of Data
Every user is ... special. Production data helps to find edge cases that would not have been thought about even in the wildest developer [dream/nightmare]. If you're testing a form with a name field, chances are you'll test with "test test" or your own name. Same chances would suggest that your name is not "Geschwindigkeitsüberschreitung Füße." Make your peace with this one. You can never reproduce every production data scenario in your development environment. Ever. No matter how many data validators you write or how many test suites you create, you will not think about accounting for Wolfe+585, Sr. in the said name field.

Frequency of Data
This part actually reinforces the two points above - scale and predictability. Test results by a single developer, in an isolated development environment, will not provide an adequate representation of the same functionality with 10,000 concurrent connections. Similarly, even if you devise a load testing suite to test for predictable traffic patterns, you cannot account for the unknown. As a very real example, a hacker's brute force attack on your password protected admin section can, in best case scenario, lock up authentication for all your users. Worst case - your production is back on its knees.

And because (for all the reasons) development will never truly represent production, identifying and troubleshooting issues in production becomes critical for companies. But in order to do that, developers need to have access to said production (if you care about time-to-solution). Give it to them. The practice of instilling the culture that shares the responsibility for production readiness between operations and development teams has gone a long way over the past few years, whether you call it DevOps or not. Use that knowledge and experience to your advantage.

More Stories By Leon Fayer

Leon Fayer is Vice President at OmniTI, a provider of web infrastructures and applications for companies that require scalable, high performance, mission critical solutions. He possesses a proven background of both web application development and production deployment for complex systems and in his current role advises clients about critical aspects of project strategies and plans to help ensure project success. Leon can be contacted at [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


@DevOpsSummit Stories
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
Enterprises are universally struggling to understand where the new tools and methodologies of DevOps fit into their organizations, and are universally making the same mistakes. These mistakes are not unavoidable, and in fact, avoiding them gifts an organization with sustained competitive advantage, just like it did for Japanese Manufacturing Post WWII.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.