Systems Architecture

Systems Architecture and Design

In order to understand modern systems architecture, it’s necessary to first understand what a computer system would look like if no thought was given to its design.  Bearing in mind that architecture covers both design patterns and systems governance (things like security, deployment topology, infrastructure design, and so on), a system that was given no architectural consideration would probably be a single monolithic application.  Perhaps all the code would be written in a single project, or even file, with no clear delineation in responsibility between different functions.  Extending it would likely be a nightmare, and the application would probably unwittingly reimplement classic security flaws that have been solved for decades.  Multiple teams working on the application would constantly be merging code with each other, and the entire thing could only be deployed at once in a big bang.  Fortunately, the art of systems architecture has built up a solid foundation of good practice to help us avoid such pitfalls.  Our expert tutors at 24HourAnswers are well-versed in the subject and ready to help you solve your own problems when considering various aspects of architectural design, and able to explain key concepts to you such as the ones explored in this article, if you need additional assistance. 

Regrettably, there are still plenty of monolithic systems around today.  These applications will struggle to perform under load, have length security reports written up against them, and usually have very frazzled teams of developers supporting them.  Should you choose to become an architect, you may end up working with one such system.  We cannot expect organizations to throw out and completely rewrite these applications, so transforming them into something more manageable is a key concept.  This is known as monolith decomposition.  But before we can understand this idea, we need to understand what we are trying to turn the monolith into. 

Microservice architecture

A system that has been architected to make use of microservices is a distributed system.  This means that various aspects of its functionality reside within entirely separate code modules which can be independently developed, versioned, and deployed.  They typically are owned by different teams who, given the ability to release software independently of each other, can iterate quickly over a given work item to extend or fix some aspect of that microservice.  The design philosophy of microservices exists independently of any language, framework, or environment you use, whether it be .NET, Java/Javascript, Python, or anything else.  This is because it merely addresses how to build up the functional units of a system – i.e. its individual applications and services.  So just exactly how micro is a microservice?

This is a common interview question and a subject of debate in the industry.  Indeed, there is no right answer (although obviously there are wrong answers!) and it’s something you’d be expected to develop your own opinion on over time.  A key concept to keep in mind is the single responsibility principle, which stems from the SOLID principles.  When applied to microservices, this means that one service should do one thing, and do it well.  Let’s look at a fictional, simplified example:

This diagram represents the architecture of a web store.  Each box represents a component, or system, in that web store.  Some are back-end services that communicate using REST or service bus messaging.  Some are front end applications responsible for rendering the store in a browser or mobile device.  Others are databases that house data and are independently deployed.    The lines between the components represent integration points between them – i.e. the search service needs to consult with the catalog to understand which products are available.  As you can imagine, if this were a monolith, every aspect of the store would be managed by the same application.  If we suddenly get a spike of thousands of new visitors per second because our store was namedropped by an Instagram celebrity, order processing, stock availability, and all other functions unrelated to merely displaying our catalog would be impacted by the application dealing with this new peak load.  As a result, we instead have several different services that are each dedicated to one thing.  This means we can scale up, for instance, our catalog and search services, either by adding more instances (horizontal scaling) or by using more powerful hardware (vertical scaling).  Note that the former is preferable, as there is always a limit to how powerful a machine you can create, but no limit to how many you can have.  And remember, if you’re struggling to understand the concepts or the reasoning behind a design like this, our 24HourAnswers experts are available at all times to explain things like the design considerations behind such an architecture, or how you’d go about structuring your own software to achieve the same benefits.

Methods of monolith decomposition

There are several different patterns one could use to transition from a monolith to a set of microservices.  One pattern is the Strangler Pattern, which is a fairly common and popular approach.  Let’s imagine you have the monolithic version of our application above, but between the website and search functionality making so many calls to the product database, the rest of the system is suffering.  As a result, you choose to decompose the product catalog functionality out of the monolith.

To use the Strangler Pattern here, you would first assign the task of creating a new version of the product catalog to the team.  There are many considerations that must be explored in depth.  For example, how will this new service communicate with the rest of the system?  In this case, we need fast performance, so we will likely use a REST/HTTP call to an API.  How many integration points are there with this functionality?  The only way to know is by examining the code, unless you have absolutely trustworthy documentation – unlikely given the lack of previous architectural input.  It is also likely in such a system that all the data is stored in a single database.  Should you also take the time to separate this out, creating an independent product database?  These are all questions that require investigation, planning, and communication with your stakeholders before anyone even starts writing code.

Once you understand the scope of the work, your team can create the new service by following your specification and requirements.  They do not need to change the existing application at this point, as they are simply creating an additional, new service.  This can be done as a greenfield project to the highest standards – which tend to be the conditions developers love working in.  Once the new service is fully tested and live, individual calls to the old code can be rerouted to use the new service, one by one.  This means the changeover to the new microservice is gradual, safe, and easily reverted.  By the end of the application of this pattern, you are left with the new service handling all calls and interactions with the product catalog, and the old code that used to handle this function is obsolete, ready to be removed at a convenient time.

If you have a question about the Strangler Pattern, or any other form of monolith decomposition (such as Change Data Capture or more detail on Database Decomposition), remember that you can contact our expert tutors at 24HourAnswers for more advice on these topics, and anything else in the realms of computer science.

Containerisation

Fully understanding containerisation would be beyond the scope of this article.  However, it is worth being aware of as a starting point.  Containerisation uses technologies such as Docker and Kubernetes to separate, define, and orchestrate microservices into their own virtual machines.  A container is defined by a Dockerfile, which will list everything this service needs to run, starting with an operating system.  Various other components are then layered up – for instance any framework dependencies, or other applications that your service needs.  Lastly, the application itself is copied into the container.  In the example below, you can see that we start by inheriting the Alpine image (a popular Linux distro) version 3.5 with the FROM keyword.  Then, a number of dependencies are added by either using RUN to call installers or COPY to write some files.  The last two steps are to call EXPOSE, opening a port for the container to communicate on, before finally executing the service that contains the user’s Python application.

(Image courtesy of Docker Labs git repository)

Docker knows how to interpret these files and takes care of hosting and running them for you.  In large production systems, the trend is to use a Kubernetes cluster to orchestrate the lifecycle of these various containers.  Kubernetes (sometimes written as K8s for short) monitors running containers on pods, restarts them if they are down or unresponsive, scales them in response to spikes of load, and ensures there are enough instances of each service running. 

In a microservices context, it’s easy to see why this technology is beneficial.  Our microservices can sit in entirely separated virtualised environments without interfering with each other’s operation.  They can be easily scaled independently to cope with varying patterns of load throughout our system, and they can be deployed seamlessly without bringing your application down.  It also means that when developers are developing the application, they are writing it for exactly the same environment as it will run on in production.  For instance, per the above example, we know for a fact that a compatible version python will be installed in the pod because it’s been defined in the docker file.  If these services were simply running natively on a server operating system, we would have to have additional processes around deployment to ensure such dependencies are correct, uniform, and present. 

Governance

Whilst we have talked to some degree about modern systems architecture, designing such systems is only one part of the role of an architect in a software-focused organization.  The other key part of the role is governance.  But what do we mean by this?

The Open Group, who define the TOGAF framework, define governance as “the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.”  In short, this can be thought of as the process of setting, maintaining, and monitoring standards within a company.  This will include, but not be limited to:

• Deciding which forms of technology are acceptable to use to write software;
• Defining the security requirements all software must follow;
• Establishing how the company will remain compliant with laws like GDPR, MIFID II, or local data protection legislation;
• Documenting how centralised telemetry and logging are implemented;

And any other area which has common architectural impact on all software teams.

Architects engaged in governance at an organisation will meet with each other to discuss the shared approach they wish to take, produce documentation that defines their standards, communicate those standards to developers, and ensure the standards are being followed.  If software is developed that is in breach of the organisational standards, the lead engineers and architects will be held responsible for why and how the breach occurred, and will be expected to explain how and when things will be put right.  All of these concepts can be discussed at length with our resident experts at 24HourAnswers, who can help you understand everything ranging from the meaning of legislation such as GDPR to how systems can implement diagnostic logs in an industry standard manner.

Why students should use our service

As you learn more about systems architecture, our tutors are available to help every step along the way. We have highly qualified tutors who have a broad range of knowledge across the domain of architecture. If you are just beginning to understand how to structure programs, we offer introductory support and online homework help, where tutors can assist you with design considerations and planning how to structure your solutions. We offer this either through live tutoring or through writeup deliverables, in which the tutor delivers you clearly written code with explanations to demonstrate how to apply architectural concepts and solve challenges in programming. For intermediate students working through larger projects, our experts are available to help guide the design and development of services and APIs, providing advice, feedback, and making changes and revisions to the design as needed. And for advanced users stuck with difficult concepts like asynchronous communication and containerization, we have experts who are seasoned veterans in solving software design problems and applying industry gold-standard techniques, available to explain or solve the toughest challenges in computer science.

24HourAnswers has been helping students as an US-based online tutoring business since 2005, and our tutors have worked tirelessly to provide students with the best support possible. We are proud to be A+ rated by the Better Business Bureau (BBB), a testament to the quality support delivered by our tutors every day. We have the highest quality experts, with tutors from academia and esteemed institutions such as the Massachusetts Institute of Technology (MIT). 

Our software architecture tutors are available anytime to offer solution design assignment help or guide you in creating complex computer systems as part of your coursework. For any architectural or design challenge—big or small—bring us the question, and we have the answers! 

If you are interested in following developments in systems architecture, you should check out the Journal of Systems Architecture. There are also many good books on the subject, one of which is Systems Architecture, by Stephen Burd, which has the advantage of being a relatively inexpensive paperback.

To fulfill our tutoring mission of online education, our college homework help and online tutoring centers are standing by 24/7, ready to assist college students who need homework help with all aspects of systems architecture. Our computer science tutors can help with all your projects, large or small, and we challenge you to find better online systems architecture tutoring anywhere.

Alexander Sofras is a technical architect with over 20 years of programming experience and 10 years in industry. He currently works in e-commerce and specialises in product discovery and recommendations.