In part one of this blog series we discussed how there is oftentimes a lack of knowledge when it comes to infrastructure technology and knowhow in the relevant DevOps teams. This is not what was intended when “Agile” moved from being a pure development approach to a whole technology management methodology, but it is where we find ourselves. One of the consequences we face because of this is that the traditional user of many technologies, the developers/application owners, know what functionality they should have but not where to get it.
Most businesses have multi-function printers that can fax, scan, and copy. In our roles, we are multi-functional as well. A network architect is often the operational troubleshooter because of his/her knowledge and expertise. The financial expert can take on the role of the supply logistics because of their understanding of the parts and processes involved in the day to day business.
In today’s world, digital transformation has changed how people interact with businesses and conduct their work. They interface with applications on the network. These applications need to be responsive and provide a quality of experience that enables people to appreciate the business and the services they provide. When an application degrades in performance, it negatively affects the user’s experience. This negative experience translates to lost value to revenues, brand, and worker productivity.
Today more than ever, the success or failure of our digital enterprise rests on whether our customer has a good user experience. No one wants to use something that is difficult to use or unreliable, and most of us don’t want to use something unless the user experience is consistent. All too often, organizations expend all their energy into making their tool /application look good, be easy to use or making it have great functionality. What they forget is that performance, especially consistent performance, can be just as important. All these things rolled into one are what I call the convenience factors. It’s not a new concept and many brick-and-mortar companies have failed over the years because of this. If we go back a few years, we can see many examples of technology or companies succumbing from an original position of strength because they never took this perceived convenience/quality factor into account. Three examples:
One of the biggest challenges we continue to see in the evolving cloud and DevOps world is around security and standards in general.
The general lack of accumulated infrastructure knowledge coupled with the enthusiasm with which DevOps teams like to experiment is causing significant challenges for corporations in terms of standardization. This is leading to two primary symptoms:
The healthcare industry must take security and privacy seriously. They collect and retain personal health information (PHI) and financial information while providing life-saving medical care. The protection of this information and the networks that manage it is one of the top concerns for IT organizations in the healthcare industry.
Several years ago, the monolithic approach to application development fell out of vogue because time to market became the key success metric in our ever-changing world. Agile development started to become the norm and the move to DevOps was born. At the same time as this change was taking place, there was another ground breaking development: the advent of public clouds. Either change by itself was industry -impacting but the two happening at the same time, both enabling each other, changed everything.
Many organizations, such as Netflix and Amazon, are using microservice architecture to implement business applications as a collection of loosely coupled services. Some of the reasons to move to this distributed, loosely coupled architecture is to enable hyperscale, and continuous delivery for complex applications, among other things. Teams in these organizations have adopted Agile and DevOps practices to deliver applications quickly and to deploy them with a lower failure rate than traditional approaches. However, you have to balance the complexity that comes with a distributed architecture with the application needs, scale requirements and time-to-market constraints.
It is the time of the year where adults and children alike put on costumes and go out to gather candy or create mischief. The costumes are scary or cute, but always achieve the goal of obfuscating the individual and hiding their true identity and intent. The person wearing the costume does not express their goal until they are interacting with their target.
Many years ago, one of my customers had an internet-facing application. They positioned load balancers in front of the application to support the growing traffic load. Traffic to the website was growing so fast, that parts of the network infrastructure could not support the customer load.