The challenge of software architecture

The challenges in today’s software architecture are highly complex.

BK: This article is aimed at companies with complex software solutions with front-ends and back-ends as well as dedicated deployment processes.

The focus is on all those involved, as well as on trends and, above all, a broad overview of the technologies that can be considered for a software architecture.

In my opinion, software architecture today should be closely linked to management, just like marketing, so that architecture decisions can be taken from the top. This also requires a certain understanding of technology at the top management level.

Today, a software architect is in an interface position.

– He/she should be able to assess the skills and the market of the developers, as this has a direct impact on the costs.

– He/she should gather the know-how of the developers, project managers, operations staff and DevOps managers in order to build the architecture.

– He/she should pick up and understand the use cases that arise from the customers.

– He/she should bring about decisions on technologies for use in architecture in order to win majorities for ideas.

– She/he should be able to inspire for a solution.

– He/she must be able to visualize the solution from different perspectives and levels of consideration.

– He/she needs an understanding of security as well as of the lifecycles to which software manufacturers are subject.

– He/she should be able to inform the stakeholders (CIO, CTO, COO, CFO, CEO and project manager) and convince them of the sense and necessity of the project.

The challenge

I see the biggest challenge in the fact that software architects are usually developers and therefore think primarily in technical terms. Business is usually a long way away and, above all, customer orientation. Developers are usually rather introverted personalities who have little understanding of marketing and sales.

However, marketing and software architecture are the driving forces behind every company today and should work hand in hand.

As soon as software is written internally, the processes today are very demanding, as build and deployment processes are involved in all modern languages.

An application with a Java backend and a modern frontend serves as an example.

Such an application usually requires the use of 15-30 different technologies that have to interact perfectly.

Version Control: Git
Infrastructure: AWS
Development environment: IntelliJ
Backend language: Java
Backend Framework: Java Spring
Backend Build System: Maven
Backend Deployment Container: Docker
Data transfer: JSON
Data transmission protocol: https (get/post)
Backend database: MySql
Frontend environment: Node.js
Frontend structure: Angular CLI
Frontend language: Typescript
Frontend Build System: Webpack
Frontend page structure: HTML5
Frontend page display: CSS3
Web server: Apache

All these parts of the application must also exist in at least 3 versions as DEV, TEST, PROD environments. At the same time, depending on the choice of architecture approach, each individual part of the list becomes arbitrarily complex. For example, when working with microservices on the backend side, the build process of the Java components becomes a science in its own right, as does the construction of the required database instances.

Each of the listed technologies is operated by different manufacturers. In many cases, there are different manufacturers with different distributions. Some parts are open source, others are commercially distributed, so that complex license models are in use.

What is often somewhat neglected by developers is that a system is characterized during operation by the fact that it can be monitored efficiently. This requires a homogeneous and comprehensible log mechanism as well as a sophisticated monitoring system.

This is the world of software architecture today!

3 types of software architectures

I am not a purist! Accordingly, I see the challenge in software architecture as creating a sensible mix of different approaches that results in the greatest possible efficiency in handling the solution.

Monolith

This approach reflects the old world of software architecture, in which various older software solutions still live, but are increasingly being replaced.

The complete software solution is developed using the waterfall method. Waterfall means that the software solution is delivered as a complete distribution. This means no use of agility. As soon as the entire solution is ready, it is deployed and tested, corrections are made and, in the best case scenario, it is deployed into production.

Many solutions that were developed in this way in the past never reached productive use, as defects could not be rectified in the productive environment or the development costs were simply no longer affordable at some point.

In the case of further development of a monolith, no individual components can be tested and deployed. For a new version, the entire application must be prepared again for a release.

This approach can have a positive effect if a highly stable solution is created, as all parts are perfectly matched to each other.

A negative aspect of the monolithic approach is that release cycles are sluggish. Furthermore, there is no possibility for dynamic scaling of such software. Accordingly, it is directly tied to the hardware, where servers have to be physically expanded in order to cover a larger load.

Just because this approach is not highly modern does not mean that it does not make sense in individual cases.

SOA – Service Oriented Architecture

Service-oriented software architecture is a step away from the monolith in the evolution of software architecture.

Different parts of the software architecture are divided into individual services, which at best can be deployed and tested independently. In an SOA, the exchange of information is usually organized via XML (Extended Markup Language), where a contract is defined between the services involved in the interface via the XSLT stylesheets.

SOAs are suitable for agile development, but the individual services are usually not completely independent.

An SOA can be very efficient and useful, depending on the requirements and area of application. Nevertheless, it does not fit perfectly with the Serverless Services approach, which is described below, as in practice the deployment processes usually have to be very precisely coordinated in order to fulfill all contracts under the services.

I see a disadvantage in the fact that the services are not completely independent, which means that they still cannot be developed and deployed completely independently of each other.

SOAs are still very common in the software industry and this approach to architecture has a clear right to exist. In various cases, I tend to abstract some of the microservices described below as SOAs themselves.

Microservices

Microservices are the most modern approach in software architecture.

In their pure form, these are completely independent and all fulfill a precisely defined purpose. The exchange of information between the services takes place exclusively via REST interfaces and the idea is to avoid dependencies wherever possible. In the case of asynchronous requests, it also makes sense to use message queues, although each of these has its own pitfalls.

The difficulty in working and software architecture with micro services lies primarily in how finely they are defined and how puristically the concepts of this architecture are used.

2 scenarios must be considered in detail:

– As the services in a micro services architecture require more communication paths, delays in these can paralyze the application. Appropriate mechanisms are needed to intercept these delays in the exchange or, if possible, to exclude them from the outset from a design perspective.

– The deployment process can become very complex, so that the optimization gained during development is nullified in the distribution process.

Micro services are preferable to the other two architectural approaches if possible, especially in view of the development of the infrastructures described below without specific servers.

Each of the three approaches has its advantages and disadvantages, which need to be carefully weighed up in detail. In my view, in a rapidly developing environment, care should always be taken to pursue models that are as progressive as possible. Alternatively, you run the risk of having to completely redesign and rewrite applications every two years, which entails high costs and can bring a company to its knees.

I consider it negligent to operate solutions based on technologies that are not kept up to date by the manufacturer, as they can create serious security vulnerabilities. These can be used by hackers for espionage in order to penetrate the internal area of a company and thus cause great damage.

Anyone operating their own software solutions is taking on a position of responsibility and should always be clearly aware of what this means for the company at any given time.

From a security perspective, each micro service should be responsible for its own security. The endpoints for interaction at the interfaces should be secured accordingly. Particularly with a view to serverless service architectures, each micro service should be programmed in such a way that it is always secured in the open Internet, even if it is used behind a firewall.

This is not always easy to accomplish and it should be noted that there is no such thing as complete security. Modern programming languages use various modules and many of these modules have security leaks that are dynamically closed by the development teams on the manufacturer’s side. Unfortunately, the developers have only limited influence on these, so that the success of hacker attacks cannot be ruled out.

Here too, the software architecture plays a central role in clarifying the security level to be used.

DevOps

Development and operations are growing ever closer together and software architects should be in close contact with both areas.

Many architectural decisions require information from both areas and, especially with serverless architectures, cloud infrastructure providers offer numerous services that no longer need to be reprogrammed. The DevOps team usually knows more about these than the developers and an exchange between these areas can prevent unnecessary costs.

Server based infrastructure

In the old world, dedicated server infrastructures are built for the software, although in recent years these have shifted from dedicated hardware to data centers where virtual machines VM’s are rented. In data centers, large numbers of computers are connected together to form clusters running a special operating system. This enables the dynamic distribution of performance and storage capacity from clusters to individual VMs.

Even if data centers offer more scaling options thanks to cluster solutions, they are still tied to one location and a maximum hardware composition.

I don’t see the hosting providers that operate these data centers being able to keep up with the large cloud infrastructure providers in the near future.

Serverless Services

Serverless infrastructures are real cloud infrastructures such as Amazon AWS, Microsoft Azure, Google Cloud, Alibaba Cloud and a few others.

These infrastructures are not tied to physical hardware and can be scaled around the world. It is a new approach that was introduced by Amazon in 2006 and is becoming increasingly popular.

Amazon AWS is still the clear market leader, but each of the major providers brings special services to the market.

What characterizes this new form of computer power is that computing power and services can be purchased dynamically by customers. Traditional data centers cannot keep up with the pricing of the tech giants. Google also provides an infrastructure for AI and machine learning in its cloud services. It is possible that services will also be made available on Google’s Quant Infrastructure in the future.

Even if various concepts such as proven relational databases e.g. MySql can be installed on the cloud infrastructures, solutions should still primarily be sought using the tools provided by the platform.

Migration of outdated solutions

Software solutions become obsolete!

In my view, there are two scenarios to consider:

– Migration in steps

If a migration is planned in stages, it makes sense to differentiate between the provision of the infrastructure and the actual development of the application.

Parts can be prepared simultaneously in both areas to speed up the development process.

It is important to ensure that new micro services are not deployed as a function of the existing system so that a clear distinction can be made.

– Complete reprogramming

I prefer reprogramming when replacing outdated solutions. This ensures that old paradigms and approaches do not survive and continue to haunt the new system.

There is always a discussion about the costs involved, but especially when the developers who originally designed the system are no longer around, a lot of time is lost in building up knowledge about the program logic. Nevertheless, after at least 3 years of operation, it is to be expected that completely new ways of programming have become established in the meantime and framework trends have shifted considerably.

Conclusion and comments

The development of micro services on Serverless Services infrastructures has only just begun. Nevertheless, it is probably unstoppable and it is a good idea to jump on the bandwagon!

The article is largely based on my own experiences in development and the intensive examination of the theoretical side through various online sources.

For detailed explanations of Micro Services, I recommend accessing Mark Richards‘ YouTube channel.