Being at the forefront of new CI/CD, Cloud native and other technological advancements is great. It’s very interesting to see and participate in anything that has to do with application and infrastructure modernization. From a personal point of view I love PoCs and to explore new tools and evaluate new ways of working. All from various perspectives to help organizations around the globe. Since a lot of companies look at each other to define “their next step” in which they follow “the common paths” you might miss some interesting topics. Let’s explore three surprising statements that make you think.
The following statements I found on the internet require a deeper look since they might look rather unconventional.
Statement 1: move fast and break things?
According to the article on TheNewStack, you will miss things if you move too fast. The first statement Jessica Cregg points out has to do with speed: “rushing harder, faster, stronger” has no meaning at all if you are going in the wrong direction. There is too much focus on tech, but with this given mindset, teams will burn-out and you will never solve problems at all. Customers are not helped and there is a lack of focus on true quality.
Processes matter when you want to move fast and fixing things that break. Jessica referenced the State of DevOps report which highlighted the enormous gap between elite performing DevOps teams versus the low performers. Without processes, teams are lost when it comes to the following areas: what actually to do when things break, how to response to incident alerts and how to best release new features to production.
Your organization must set the right direction for the teams, to let them all become elite performers instead of just “running fast”. Psychological safety for team members still matters to keep them confident that they actually can can run fast and break things and learn and recover from it as soon as possible.
One final tip that the article reveals: engage more people in the “why”, “how” and “what” questions that all have to do with decision making. It’s vital for people to feel comfortable and to speak up. This might sound like you’re slowing down – since it may lead to a lot of discussions – but you’ve got all the voiced heard. Developer happiness remains a key priority, especially when it comes to define their own tooling.
All of this helps to actually move fast, break things and getting back on your feet to start running again.
Statement 2: Uncloud
Many, if not all, companies rush to the cloud, especially since the Covid pandemic hit us all last year. Companies needed to answer challenges like: how to connect everyone from their home address to the corporate network, how to keep those new individual workspaces secure, what about other tooling. It also boosts application development and deployment to the cloud.
From this perspective, companies used to have strategic goals like “cost savings” to migrate to the cloud. It’s their view that they always safe costs when adopting cloud technology, no matter what their strategy is or how they actually operate the cloud and integrate it into their current work processes.
Some companies do it differently. They are not moving to the cloud or leaving the cloud for various other reasons. Some of the arguments in the following article which are mentioned are:
- Cloud first initiatives are pushed by cloud providers themselves, making it a biased choice. There is a limited counter balance to this movement. However there are strong arguments when cloud does not fulfill it’s proposed benefits.
- Don’t start with the solution. Moving to the cloud starts for whatever reason, not taking into account the real the business arguments. Organization who forget this, miss out so many important aspects. It will lead to huge costs, long lead times, disappointed results and frustrated employees.
- Organization who actually make the move to the cloud, tend to forget the so called “exit strategy”.
So what are common reasons of companies that move out of the cloud? The frame of reference would be the article I mentioned before.
Cost savings?
Ironically and perhaps the most important one: reduce costs. Suppose you would run an infrastructure team to take care of your in-house data-center. That team now changes shape and has to build a cloud operating model and cloud platform for DevOps teams to operate in a secure way in the cloud itself. Secondly, consider storage solutions. Your Virtual Machines can be switched off or even completely discarded during out of office hours, storage solutions still incur money. Scaling up and down is a big benefit when using cloud technology, however many companies only require scaling up and down during predefined peak moments which are very limited. They are not required constantly, so this argument does not hold here.
Given all of these legitimate arguments, every company has to make a careful decision about their intended migration. Business cases need to be detailed enough and include portfolio management to give a proper answer here.
Statement 3: Shifting right, testing in production
Everyone shifts their CI/CD related efforts left. Especially (security) testing and other ways to verify your applications meet a certain requirement. Now we also know the concept of “shifting right”. According to the article on ToTheNew.com, we should be testing in production. That’s a shift right. Interesting and challenging.
Testing in production is very valuable to simulate what happens in a real world scenario. As of today, most of the companies are only smoke testing and sanity testing in production. A lot of them struggle to keep their test and acceptance environments in sync with their production counterparts. However, there are always limitations that prevent you from mimicking the ideal situation.
Frequently deploying to production helps to keep an eye on the perceived risks. Bugs are detected earlier on in the process and the whole process of actually deploying to production helps to gain more experience. People can respond to it in a quick way.
Advantages
Besides this, consider the following subset of following advantages:
- Detect bugs and other malicious attacks which might slip through the cracks of QA testing.
- Real-time monitoring the API responses at peak traffic.
- Detect network failures, weak connections and call interruptions which would otherwise pass unnoticed.
The dont’s for testing in production are: only test if there is less load on the application, use your own credentials, never conduct load tests and don’t tamper with other users’ data.
Conclusion
A lot has been written already about cloud advantages, moving fast and break things plus shifting nearly everything left (to the DevOps team). The above-mentioned statements triggered my mind to explore the reasons behind hit. It sheds new light on the common topics and are worth considering if you are involved into one or more of these topics. I hope you liked it and you will challenge whatever is there to be decided about it in your organization.
If you have more questions related to these topics, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.