AWS developer advocate: 3-cornerstones for building modern cloud apps
This is a guest post for the Computer Weekly Developer Network written by Steve Bryen in his role as senior developer advocate for UK and Ireland at Amazon Web Services.
Among the several key trends driving modern application development in the cloud arena, Bryen points to security, compliance and the need for clearly defined individual microservices ownership as significant pointers to guide developers in contemporary cloud-centric (or, cloud-native, even) code-shops.
Bryen writes as follows…
Security should always be the number one priority when building modern applications. It’s one area that we cannot lower the bar on.
We do not want to slow developers down and just block or restrict the tools available to them (although it’s true to say that these are often the behavioural traits of traditional InfoSec teams)… but it’s important to realise that the world of modern cloud-based development is different.
Developers now have some decisions to make around security, above and beyond what they would have to take on board (and look to manage) in a traditional world.
Looking into cloud visibility
Think about permissions management for serverless functions, object storage access policies etc. These are some examples of things a developer may now have to take care of. But don’t get the wrong impression i.e. by no means are modern apps less secure — it’s quite the opposite.
Building modern apps in the cloud allows you to gain greater visibility and control than is often possible when you’re operating on-premises across multiple heterogeneous hardware and software vendors.
Providing agility and openness doesn’t mean letting developers run amok, or letting go of the control we know we need to stay secure. It’s about giving guardrails and baseline configuration enforcement. Security automation is vital here and this is where having standardised APIs and auditing tools in the cloud helps to improve security posture and the ability to maintain control, without being a blocker.
Going deep, going wide
Another good practice is to move security capabilities much, much deeper into the software engineering space. We need to be sure that we are building in security and compliance across the entire application life cycle; this includes skills as well as tooling.
From a skills perspective, this means having infosec skills in your software development teams. But also having software development skills in your security teams. This enables the good practice of implementing security automation. Security Automation allows us to make sure applications are behaving as intended and built as per guidelines. We need to consider using automation where possible at each step of the application lifecycle and ensure that data is encrypted both at rest and in transit.
“You build it, you run it”
The notion of “you build it, you run it” is a quote from an interview with Amazon CTO, Werner Vogels in 2006 – and let’s remember, that was a time way before the term DevOps was even a thing.
So let’s think about that drive to build, deploy to production, stand back… there is still a need to think about how you build and run i.e. when it comes to modern cloud-based apps, each of the microservices that you build should have a clearly defined owner.
End-to-end is now further apart
Beyond just owning the software engineering piece of the equation, that cloud developer is also responsible for operating the system once it is in production, along with the end-to-end deployment process.
Adopting this approach at AWS has not only helped us to build better software, it has also brought our engineering teams much closer to customers.
From a practical perspective, you no longer build your software and then throw it over the wall to operations or QA to take care of it. Each team responsible for a microservice also owns the whole deployment process end-to-end.
Pick a pipeline
One thing to consider, is breaking down those traditional deployment pipelines into individual-specific pipelines, tailored to your services needs. This pattern does require some cultural change in your organisation, as well as technical, but the potential upside of higher quality features and closer customer engagement makes it worthwhile.
These foundational practices and others should act as a good starting point for staying competitive, moving fast and providing features to customers more frequently, all while remaining secure, reliable and highly available.