Architecture

Most new applications are built as a single codebase and deployed as a monolith until product-market fit or the need for additional scale is required. Such monolithic applications are easy to write and maintain, and allow you to iterate quickly when there are a smaller number of users and the traffic is low. However, as traffic increases you will need to scale the application to handle the increase in load. One framework for scaling is the “Scale Cube” describe by AKF partners. ...

Application Portfolio Management (APM) draws inspiration from financial portfolio management, which has been around since at least the 1970s. By looking at all applications and services in the organization and analyzing their costs and benefits, you can determine the most effective way to manage them as part of a larger overall strategy. This allows the architect or engineering leader to take a more strategic approach to managing their application portfolio backed by data. Portfolio management is crucial for creating a holistic view of your team’s technology landscape and making sure that it aligns with business goals. ...

When people describe progress, they often describe it in terms of a linear progression taking us from primitive to advanced — an idea or invention occurs as a singular event, and somewhere further down the line of time a new idea or invention completely replaces it, relegating the old to the annals of history. This viewpoint is exemplified by traditional worldviews that organize all beings according to a chain of evolution, sometimes called the “great chain of being” (or scala naturae). The chain of being links God, angels, humans, animals, plants, and minerals in a hierarchy. All beings on earth, animate and inanimate, could be organized according to an increasing scale of perfection, from mushrooms and rocks at the bottom up through lobsters and rabbits, all the way to human beings and God at the top. ...

In the book “Thinking in Systems”, Donella Meadows dedicates an entire chapter to explaining why functioning systems seem to work so well. In it, she recognizes three characteristics: resilience, self-organization, and hierarchy. Resilience We can use the standard definition from the Oxford English dictionary to describe resilience: re·sil·ience /rəˈzilyəns/ noun the capacity to recover quickly from difficulties; toughness. “the often remarkable resilience of so many British institutions” the ability of a substance or object to spring back into shape; elasticity. “nylon is excellent in wearability and resilience” According to Donella Meadows this definition can be translated to systems as the “ability to survive and persist within a variable environment. The opposite of resilience is brittleness or rigidity.” ...

As a software system scales it becomes sufficiently large that the number of working parts, coupled with the number of working programmers making changes on it, makes the behaviour of the system extremely difficult to reason about. This complexity is exacerbated by the transition of many organizations towards a microservice architecture, as exemplified by the so-called “death star” architecture, where each point in the circumference of the circle represents a microservice and the lines between services represent their interactions. ...

All healthy technology discussions should begin with business goals and use those goals as a reasonable set of guidelines to focus technology investment decisions. These business goals are best articulated from a deep understanding of what the company, the product team, or the marketing team want to accomplish. In a business-first model, technology is forced to balance the desires for technical effectiveness and efficiency with the operational needs of the business. This balance can be difficult to achieve if you’ve ended up in a leadership position from a technology background — you are used to solving problems by writing code and it becomes difficult to think of other ways to solve them! ...

One of the recurring themes of any technology discussion is programming language. It doesn’t take much effort to find blog posts with dramatic headlines (and even more dramatic comments) about how shipping a new project with Haskell or Clojure or Elm improved someones job, marriage, and life. These success stories are posted by raving fans that have nothing but the best to say about their language of choice. A common thread running through these posts is that they are typically tied to building out new, greenfield projects. I can’t help but wonder. After the honeymoon of building a new project with a new programming language, what happens next? Is it all bubble gum and roses? ...

Microservices have become part of the software engineering cultural zeitgeist to the extent that alternative approaches to architecture and development are treated as somehow inferior. Given the challenges that running microservices present, I usually recommend beginning development of new projects and systems as a single deployable unit — the monolith. Sam Newman, in the book “Building Microservices”, agrees with this approach. He recommends leveraging microservices only if you can become convinced of the benefits for your system, not as a default for every project. ...

In a shopping cart, the swivel wheels of the cart are set in the front, and the fixed wheels are set in the back. Now picture yourself pushing a shopping cart backwards. Almost naturally, you swivel the cart to move the front end to one side or the other before beginning to push the cart. Now picture yourself pushing a shopping cart backwards, on an ice rink. Here, the cart keeps sliding around even after you’ve stopped pushing it. Instead of going straight from one end of the rink to the other, the cart makes giant S-shaped turns. ...

Engineering, for much of the twentieth century, was mainly about artifacts and inventions. Now, it’s increasingly about complex systems. As the airplane taxis to the gate, you access the Internet and check email with your PDA, linking the communication and transportation systems. At home, you recharge your plug-in hybrid vehicle, linking transportation to the electricity grid. At work, you develop code, commit it to a repository, run test cases, deploy to production, and monitor the result. Today’s large-scale, highly complex systems converge, interact, and depend on each other in ways engineers of old could barely have imagined. As scale, scope, and complexity increase, engineers consider technical and social issues together in a highly integrated way as they design flexible, adaptable, robust systems that can be easily modified and reconfigured to satisfy changing requirements and new technological opportunities. ...