The Cloud Native Architect

In the world where everyone wants to be in the cloud because it’s the cool place to be; a movement to design applications specifically to run in a cloud environment was somewhat natural and inevitable.

I started thinking back over the past 15 years of my career. The practices that were being put in place by companies in readiness for the Enterprise Java era were based on solid foundations and years of experience of operating production systems. I had left my University degree armed with knowledge of EJB, rpc, early agile methodologies and little beyond the theory of how mission critical systems were constructed. Developers just cared about development, operations/sys admins sat in another part of the office and unless an issue came up during the initial handover period there would be minimal communication. I remember the time when I bought J2EE without EJB and it felt completely revolutionary.

The landscape

One of the biggest learning curves I ever endured in that time was working in an operations team building what I will call a virtualisation platform. They called it infrastructure as code, I called it automating previously manual processes using development techniques. It opened my mind again to a completely new way of looking at development teams outside of the DevOps culture. Development techniques were relatively new in that team but the real value was driven through collaborative knowledge share. System administrators were developing code and developers were gaining knowledge of automating and building up the infrastructure & networking of a cloud platform. At this point, this was the first time I had seen this degree of two-way communication outside of teams already building on a PaaS. This truly opened my eyes to the challenges these operations team face when the code is thrown over the fence and they are expected to agree to run it in production with confidence.

Historically the responsibilities of a production system were formed from an aggregated view of collective specialisms. For example: Infrastructure architects, network architects, security architects, QA, developers; technical and solution architects. What I am getting at here is that each role had a more narrow minded focus and set of key responsibilities.

Let’s fast forward to today, the expectations now are much different. In order to build a scalable and resilient system in our current climate it would be expected that there would be a micro services architecture somewhere behind it. Like in any distributed system it brings an additional level of complexity to deal with since the move away from three tier architectures over the last decade or so. This complexity means we are no longer dealing with transactional boundaries within the same process and application server, it’s probably not even in the same network and possibly may not even be in the same continent.

This shift must drive all members of the team to broaden their knowledge or risk complete and utter failure when moving this to production. Let’s just add another load balancer or use distributed transactions to address risk is no longer going to fly. One role which I feel can really help instil this culture is that of the software architect.

The Cloud Native Architect Manifesto

This got me thinking about the ideas that any architect should use to drive this culture and process in to the teams and organisation. How do you build and deliver applications successfully, especially for the cloud?

• Always expect the unexpected — nothing is guaranteed (expect failure)
• Influence organisational changes — (i.e if you want your teams to be building what you expect you may need to get involved in how they are structured)
• move as fast as is organisationally possible to deliver — drive teams to deliver at the appropriate speed for their burn rate but also make sure you are delivering fast enough to get out to market. Remember every business is a software business.
• Focus on your specific use case (avoid distractions), there is plenty of cool stuff out there but that’s not the right reason to use it.
• Traffic is going to come from many different channels — the goal here is a ubiquitous and flexible architecture
• Scaling should be straightforward — think 100% uptime, blue/green deployments in your definition
• Automation — so automation can cover many things, but think deployment, build, release management, testing. (still automate whats right here, 100% automation could mean moving slower without producing much value i.e. automating testing of particular areas that can be better addressed with other means)
• Thou must 12 factor — https://12factor.net/
• Try to avoid the temptation to build a PaaS — there are plenty of viable options already out there and tested in the wild
• Keep in mind the end goal — business and IT agility to deliver what we want more efficiently in to the marketplace at a greater speed. By doing this we can avoid additional overheads and gain a more streamlined delivery process which will benefit all. Organisational culture is as important here as technical choices.