This blog on how DevOps can facilitate architecture change is based on conferences and meetups the Daysha team attended in the first half of 2018.
What follows are summary views on new technology trends and our observations of how these are being adopted and used.
Driven by the logic of only building enough functionality that adds customer value and the availability of serverless, microservices the ability to build and deploy incrementally while increasing resilience is proving attractive to Fintech organisations. A large number of financial services organisations are now at the very least piloting this type of architecture. A smaller number are looking at ways of decomposing or strangling their monoliths into microservice architecture. It’s still early days for organisations that have legacy.
Coupled with the utility cost models that do not require capital investment and which have infinite scalability (cloud), DevOps teams are empowered to build quickly with reduced risk of outages. Cloud is rapidly becoming the new norm even for larger financial services organisations in terms of architecture planning but production deployments are lagging behind this. However regulated organisations are claiming they can deploy 80% of their data in public cloud and be audit compliant.
Through using containerisation as a means to avoid the configuration drift that bedevilled older dev and ops dialogues, container orchestration is maturing and Kubernetes has significant mindshare.
Other technology observations….
- Metrics…a second generation of metrical measurements is emerging as cycle times reduce. The number of times a release breaks or length of time to build. ’
- Database is hard. Very hard and when trying to move to serverless its a showstopper.
- There is clear evidence that companies who want to scale reducing investments in SDLC automations and evaluating COTS alternatives that come with built in governance.
- It is also equally clear that as orgs scale they are adopting a ‘standard’ tool chain which flies in the face of the agile manifesto to let teams select their own tools.
- A good approach to this can be to empower individuals to challenge the standard tool chain by granting incrementing time to prove a case for a new tool.
- DevOps implementations are from a central hub. Remote however has local staging and ability to go/no go on releases.
- This is evidence of lack of available DevOps skills to implement more federally but not necessarily a lack of willingness to do so.
- Organisations with aging monoliths are increasingly in search of reduced downtime as a means to drive business case for investment in DevOps.
A comparable BLOG article was published last year.