This is part 3 of a multi-part article series see other articles here:
Perfect requires ….
If you are still reading allow me to reward you with some measure of answers:
The first real challenge is change happens and you will not have the funding to remove the old and replace with the new.
The second real challenge is that innovation and agility demand change.
The third challenge is that we continue to focus on initial state instead of life of a service as a constant source of change.
So, the challenge is change.
Perfection is the process of refinement until only desirable elements, qualities or characteristics remain.
I have illustrated that change is both the problem and the solution. How can we resolve these two opposites: I love change, but I hate its effects?
. There are two IT approaches to this challenge:
- Take on day two operations (standardize, quantify, change management etc..)
- Move to micro-service architecture
Many organizations have embraced change management as the way to approach change. Every single change has to be approved by subject matter experts thus reducing risk. In practice this only serves to slow down innovation by making it filter though a committee. Management of change is the enemy of innovation. It’s truly the relish of IT’s failure today. Change management rarely stops failures because of the complexity of systems involved. While I am a huge fan of configuration management as a method of maintaining initial state it’s only a band-aid for the real solution. It’s a reactive approach which rarely takes into account the master plan.
The allure of micro-service architecture can be easily understood but in reality many applications both COTS and in-house developed struggle to achieve this as a reality. Many customers have a strategy that is single sided favoring stateless and micro-service architectures while pretending traditional applications don’t exist. A quick survey of your application portfolio might show that 80% of your business revenue is generated by the least stateless architecture you support. It’s a rip and replace plan that rarely takes into account current realities.
So how can we embrace change and innovation?
I believe this is where we combine the best of both worlds with a clear understanding of reality. We need the replacability of micro-service architecture with the compatibility of legacy servers. We need to speed and agility of constant change with the stability of configuration management. For me it’s come down to application as code. Can you define your application as code? Architects have been defining their applications in Visio for years… would it not be easier to define it as code. This code can then be versioned and updated. envision everything unique about your application from network, security, storage, servers, configuration and applications defined in a code construct. You could then check that construct into a code repository. When change is required the complete environment including change can be deployed using the code construct. The deployed infrastructure can be tested automatically for required functionality and then be used to replace current production. If it fails functionality tests then it returns to the drawing board. This type of infrastructure as code can be deploy 100 times a day driving innovation speeds. If failures become an issue the application and infrastructure are rolled back to last known good state. I am not suggesting we adoption 100% stateless infrastructure, containers or magic fairy dust… I am suggesting we tighten our belts and do the hard work to truly define applications as code. In order to define things as code we need to have three things:
- Software based constructs for everything – if your solution requires physical hardware it cannot be automated or replicated without time and cost – no one has hardware on demand for every dynamic situation
- coordination between silo’ed teams (break down the solo and form one team, no more infrastructure, application, network, security, operations)
- Development skills
Combining all these elements provide the basis for successful application as code. You will have to orchestrate many different methods into a cohesive approach and use iterative software development. In order to solve the problem you will have to approach a new project with this team not try to redesign or replatform a old one. These basic blocks can provide the basis for immutable applications thus making infrastructure just plumbing.
(everything unique about an application is replaceable)
© 2018, Joseph Griffiths. All rights reserved.