A Conversation with PWS Customer Simon Brown on Architecture and Platforms
- July 11, 2017
Simon Brown is the founder of Structurizr and “Coding the Architecture” who is an expert on the use of architecture to create better more reliable and sustainable software. He has many talks on InfoQ.com on the subject of abstraction and how to choose it. In addition, Simon is an active user of PWS. We are pleased to be able to have the opportunity to chat with him about where he thinks software development is going with respect to architecture and how deployment of applications will occur in the future. We also will get his thoughts on how a platform like Cloud Foundry works with software architecture.
Q: People often talk about “Software architecture” or “Software architects” and we all nod in agreement, but it is often on this point that people talk past each other. Can you give us your thoughts on what these two related terms mean?
A: Just a few years ago, “software architecture” and “software architect” were often seen as things that teams no longer needed to think about, primarily because of the way that people misinterpreted the Manifesto for Agile Software Development. Thankfully, this perception is now being reversed, and teams are once again understanding the importance of software architecture. For me, “software architecture” is essentially about structure and vision. If you’re building a piece of software, you need to be able to understand and describe (to other stakeholders) the structure of that software, ideally from different levels of detail. You also need to be able to create a vision for a team to work with, especially if you’re starting out with a blank whiteboard and a set of requirements or business goals. Grady Booch describes architecture as the set of significant decisions, where significance is measured by cost of change. I really like this as part of the definition, because it implies that some decisions are much more important than others.
Although the term “software architect” as a job title has negative associations for many, one or more people on a software development team do need to take care of the software architecture. In essence, it’s about technical leadership and every software development team, large or small, needs some degree of technical leadership. Whether that technical leadership is handled by one or many people depends on the maturity of the team. I like to think about this technical leadership as a role that needs to be fulfilled, rather than a specific person with a job title.
Q: Often the key to successful software architecture is choosing the right abstraction for development. What are some key aspects that one should focus on when choosing abstractions?
A: You can approach this question from a couple of different perspectives. One angle is to think about how you decompose your overall software system into different building blocks, whether that’s at the high-level (e.g. components and modules in a monolith vs a collection of microservices) or the low-level (e.g. the domain model and data structures). The key here is to really understand that there are usually many “correct” solutions, and that each solution has its own set of trade-offs. Understanding the various approaches to design and decomposition will help identify those various solutions.
The other angle is how you use abstractions to describe your software to other stakeholders. Much of the traditional literature about software architecture provides a set of abstractions that can be used to describe software systems. For example, you’ll often see teams describe their software using a “logical view”, showing the high-level components and how they interact. I’m often left feeling uninspired by such descriptions though because, in my experience, they rarely match the reality of the code. As a developer myself, I want architecture descriptions that reflect the code, and how I view the software from a developer’s perspective. This is why I created what I refer to as my “C4 model”. It’s a set of diagrams, like a set of zoomable maps, based upon a simple set of hierarchical abstractions (software systems, containers, components and code). Having a shared understanding of what is being, or has been, built is crucial to success.
Q: You have been a proponent of “Platform as a Service” or “PaaS” and in particular Pivotal Web Services and Cloud Foundry. What are the advantages of using a PaaS vs “rolling your own” as the right abstraction level?
A: There’s a lot of hype around things like Docker at the moment. And I’m a huge fan, but I don’t necessarily like the way that it’s being marketed as “a way to build better apps”. There are certainly a number of benefits to creating a single shippable unit that includes everything needed to run the various parts that make up any given software system. However, I’m concerned that many developers are jumping on this without the prerequisite operations knowledge about patching infrastructure, hardening containers, scaling, clustering, failover, log aggregation, monitoring, etc.
I think that PaaS provides a much better set of abstractions for developers to work with. In addition to the software architecture training and consulting that I do, I also have a startup called Structurizr, which is a collection of tooling to help teams visualise, document and explore their software architecture. Part of this is a Software as a Service offering, and it’s hosted on Pivotal Web Services. As an early stage startup, I have a couple of options for getting something running on the web. The first is to go down the Infrastructure as a Service route, where I build and provision all of the web and database servers that I need, potentially with Docker. As a software developer myself, (1) this is a lot of work and (2) it’s not necessarily my core skill set. With PaaS, I simply push my applications (Java .war files in my case) and the platform (PWS) does the rest.
PaaS isn’t an all or nothing proposition either. I’m using CloudFlare’s SSL service to serve content over HTTPS, SendGrid for e-mail and Papertrail for capturing the aggregated logs from PWS. And since my applications are just vanilla Java/Spring web applications, there’s no lock-in. I can deploy those applications pretty much anywhere. The real benefit of PWS, of course, is that it provides the whole platform … infrastructure provisioning, URL/application routing, load balancing, log aggregation, scaling, platform security, infrastructure patching, etc. I could certainly do this myself by rolling my own infrastructure, but I’d rather spend the time and money building out my core product offering.
Q: Is there any particular thing that you find that Cloud Foundry does well with respect to the software development process for abstracting the value added components of software development vs control of rolling your own?
A: In real terms, Cloud Foundry reduces the barrier to entry of doing continuous delivery and things like zero-downtime blue-green deployment. For Structurizr, the build script does all of the usual compilation and testing, before using the Cloud Foundry API to push the resulting applications to PWS. PWS will then provision the infrastructure, spin up multiple copies of my applications, bind any services needed and route URLs to those applications. I really like the way that I can use the Cloud Foundry API to push applications, add configuration parameters, specify the number of application instances that I need and so on. This is incredibly powerful for a small startup because it means that we can ship as many builds per day as we need to, all with zero-downtime. Again, it’s all about the abstractions. Cloud Foundry allows you to work with applications rather than infrastructure and containers.
Q: If you were to wave a magic wand, where would you like to see software development go 10 years from now?
A: I’d really like to see software development learning from it’s rich history rather than ignoring it. We keep reinventing the wheel over and over again, or jumping from one extreme to the other. There’s an ongoing debate about whether software development is an engineering discipline, and I think, to some extent anyway, it should be. But we need to build up a core body of knowledge; common practices and principles, some independent of technology, that are broadly applicable in a number of situations. I think we do have some of that, it’s just not necessarily centralised and easily accessible. The teams that I work with around the world vary enormously in their maturity and how they approach software development. Some are very mature and really understand what they are doing, others less so. I’m hopeful that, in 10 years, I won’t see so much variance across the industry.
This is part of an ongoing conversation with Pivotal Web Services customers about how they are using the platform and how the use of the platform influences their software development practices. If you have a story to tell, please contact Charles Wu ([email protected]).
