Software Architecture with Python

Chapter 1. Principles of Software Architecture

This is a book on Python. At the same time, it is a book about software architecture and its various attributes, which are involved in a software development life cycle.

In order for you to understand and combine both aspects, which is essential to get maximum value from this book, it is important to grasp the fundamentals of software architecture, the themes and concepts related to it, and the various quality attributes of software architecture.

A number of software engineers, taking on senior roles in their organizations, often get very different interpretations of the definitions of software design and architecture, and the roles they play in building testable, maintainable, scalable, secure, and functional software.

Though there is a lot of literature in the field, which is available both in conventional book form and on the internet; very often, the practitioners among us get a confusing picture of these very important concepts. This is often due to the pressures involved in learning the technology rather than learning the fundamental design and architectural principles underlying the use of technology in building systems. This is a common practice in software development organizations, where the pressures of delivering working code often overpowers and eclipses everything else.

A book such as this one, strives to transcend the middle path in bridging the rather esoteric aspects of software development related to its architectural quality attributes to the mundane details of building software using programming languages, libraries, and frameworks—in this case, using Python and its developer ecosystem.

The role of this introductory chapter is to demystify these concepts, and explain them in very clear terms to the reader to prepare his/her for the path towards understanding the rest of this book. Hopefully, by the end of this book, the concepts and their practical details will represent a coherent body of knowledge to the reader.

We will now get started on this path without any further ado, roughly fitting this chapter into the following sections:

Defining software architecture
Software architecture versus design
Aspects of software architecture
Characteristics of software architecture
Why is software architecture important?
System versus Enterprise Architecture
Architectural quality attributes
- Modifiability
- Testability
- Scalability/performance
- Security
- Deployability

Defining software architecture

There are various definitions of software architecture in the literature concerning the topic. A simple definition is given as follows:

Software architecture is a description of the subsystems or components of a software system, and the relationships between them.

The following is a more formal definition, from the Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE) technology:

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."

It is possible to get umpteen such definitions of software architecture if one spends some time searching on the web. The wordings might differ, but all the definitions refer to some core, fundamental aspects underlying software architecture.

Software architecture versus design

In the experience of the author, this question of the software architecture of a system versus its design seems to pop up quite often, in both online as well as offline forums. Hence, let us take a moment to understand this aspect.

Though both terms are often used interchangeably, the rough distinction of architecture versus design can be summarized as follows:

Architecture covers the higher level structures and interactions in a system. It is concerned with those questions that entail decision making about the skeleton of the system, involving not only its functional but also its organizational, technical, business, and quality attributes.
Design is all about the organization of parts or components of the system and the subsystems involved in making the system. The problems here are typically closer to the code or modules in question, such as these:
- Which modules to split code into? How to organize them?
- Which classes (or modules) to assign the different functionalities to?
- Which design pattern should I use for class "C"?
- How do my objects interact at runtime? What are the messages passed, and how is the interaction organized?

Software architecture is about the design of the entire system, whereas, software design is mostly about the details, typically at the implementation level of the various subsystems and components that make up those subsystems.

In other words, the word design comes up in both contexts, however, with the distinction that the former is at a much higher abstraction and at a larger scope than the latter.

There is a rich body of knowledge available for both software architecture and design, namely, architectural patterns and design patterns respectively. We will discuss both these topics in later chapters of this book.

Aspects of software architecture

In both the formal IEEE definition and the rather informal definition given earlier, we find some common, recurring themes. It is important to understand them in order to take our discussion on software architecture further:

System: A system is a collection of components organized in specific ways to achieve a specific functionality. A software system is a collection of such software components. A system can often be subgrouped into subsystems.
Structure: A structure is a set of elements that are grouped or organized together according to a guiding rule or principle. The elements can be software or hardware systems. A software architecture can exhibit various levels of structures depending on the observer's context.
Environment: The environment is the context or circumstances in which a software system is built, which has a direct influence on its architecture. Such contexts can be technical, business, professional, operational, and so on.
Stakeholder: A stakeholder is a person or groups of persons, who has an interest or concern in the system and its success. Examples of stakeholders are the architect, development team, customer, project manager, marketing team, and others.

Now that you have understood some of the core aspects of software architecture, let us briefly list some of its characteristics.

Characteristics of software architecture

All software architectures exhibit a common set of characteristics. Let us look at some of the most important ones here.

An architecture defines a structure

An architecture of a system is best represented as structural details of the system. It is a common practice for practitioners to draw the system architecture as a structural component or class diagram in order to represent the relationships between the subsystems.

For example, the following architecture diagram describes the backend of an application that reads from a tiered database system, which is loaded using an ETL process:

An architecture often conforms to a pattern

Example of client-server architecture

The following diagram describes another common architecture pattern, namely, the pipes and filters architecture for processing streams of data:

Example of pipe and filters architecture

We will see examples of architectural patterns later in this book.

Importance of software architecture

So far, we have discussed the fundamental principles of software architecture, and also seen some of its characteristics. These sections, of course, assumed that software architecture is important, and is a critical step of the software development process.

It is time to play devil's advocate, and look back at software architecture and ask some existential questions about it as follows:

Why software architecture?
Why is software architecture important?
Why not build a system without a formal software architecture?

Let us take a look at the critical insights that software architecture provides, which would otherwise be missing from an informal software development process. We are only focusing on the technical or developmental aspects of the system in the following table:

Aspect	Insight/Impact	Examples
Architecture selects quality attributes to be optimized for a system.	Aspects such as scalability, availability, modifiability, security, and so on of a system depend on early decisions and trade-offs while selecting an architecture. You often trade one attribute in favor of another.	A system that is optimized for scalability must be developed using a decentralized architecture where elements are not tightly coupled. For example: microservices, brokers.
Architecture facilitates early prototyping.	Defining an architecture allows the development organization to try and build early prototypes, which gives valuable insights into how the system would behave without having to build the complete system top down.	Many organizations build out quick prototypes of services—typically, by building only the external APIs of these services and mocking the rest of the behavior. This allows for early integration tests and figuring out interaction issues in the architecture early on.
Architecture allows a system to be built component-wise.	Having a well-defined architecture allows the reuse and assembly of existing, readily available components to achieve the functionality without having to implement everything from scratch.	Libraries or frameworks which provide ready-to-use building blocks for services. For example: web application frameworks such as Django/RoR, and task distribution frameworks such as Celery.
Architecture helps to manage changes to the system.	An architecture allows the architect to scope out changes to the system in terms of components that are affected and those which are not. This helps to keep system changes to a minimum when implementing new features, performance fixes, and so on.	A performance fix for database reads to a system would need changes only to the DB and Data Access Layer (DAL) if the architecture is implemented correctly. It need not touch the application code at all. For example, this is how most modern web frameworks are built.

There are a number of other aspects which are related to the business context of a system, into which architecture provides valuable insights. However, since this is a book mostly on the technical aspects of software architecture, we have limited our discussion to the ones given in the preceding table.

Now, let us take on the second question:

Why not build a system without a formal software architecture?

If you've been following the arguments so far thoroughly, it is not very difficult to see the answer for it. It can, however, be summarized in the following few statements:

Every system has an architecture, whether it is documented or not
Documenting an architecture makes it formal, allowing it to be shared among stakeholders, making change management and iterative development possible
All the other benefits and characteristics of software architecture are ready to be taken advantage of when you have a formal architecture defined and documented
You may be still able to work and build a functional system without a formal architecture, but it would not produce a system which is extensible and modifiable, and would most likely produce a system with a set of quality attributes quite far away from the original requirements

System versus enterprise architecture

You may have heard the term architect used in a few contexts. The following job roles or titles are pretty common in the software industry for architects:

The Technical architect
The Security architect
The Information architect
The Infrastructure architect

You also may have heard the term System architect, perhaps the term Enterprise architect, and maybe, Solution architect also. The interesting question is: What do these people do?

Let us try and find the answer to this question.

An Enterprise architect looks at the overall business and organizational strategies for an organization, and applies architecture principles and practices to guide the organization through the business, information, process, and technology changes necessary to execute their strategies. The Enterprise architect usually has a higher strategy focus and a lower technology focus. The other architect roles take care of their own subsystems and processes. For example:

The Technical architect: The Technical architect is concerned with the core technology (hardware/software/network) used in an organization. A Security architect creates or tunes the security strategy used in applications to fit the organization's information security goals. An Information architect comes up with architectural solutions to make information available to/from applications in a way that facilitates the organization's business goals.
These specific architectural roles are all concerned with their own systems and subsystems. So, each of these roles is a System architect role.
These architects help the Enterprise architect to understand the smaller picture of each of the business domain they are responsible for, which helps the Enterprise architect to get information that will aid him in formulating business and organizational strategies.
The System architect: A System architect usually has a higher technology focus and a lower strategy focus. It is a practice in some service-oriented software organizations to have a Solution architect, who combines the different systems to create a solution for a specific client. In such cases, the different architect roles are often combined into one, depending on the size of the organization, and the specific time and cost requirements of the project.
The Solution architect: A Solution architect typically straddles the middle position when it comes to strategy versus technology focus and organizational versus project scope.

The following schematic diagram depicts the different layers in an organization–Technology, Application, Data, People, Process, and Business, and makes the focus area of the architect roles very clear:

Scope and focus of various architect roles in a software organization

Architectural quality attributes

Let us now focus on an aspect which forms the main topic for the rest of this book–Architectural Quality Attributes.

In a previous section, we discussed how an architecture balances and optimizes stakeholder requirements. We also saw some examples of contradicting stakeholder requirements, which an architect seeks to balance, by choosing an architecture which does the necessary trade-offs.

The term quality attribute has been used to loosely define some of these aspects that an architecture makes trade-offs for. It is now the time to formally define what an Architectural Quality Attribute is:

"A quality attribute is a measurable and testable property of a system which can be used to evaluate the performance of a system within its prescribed environment with respect to its non-functional aspects"

There are a number of aspects that fit this general definition of an architectural quality attribute. However, for the rest of this book, we will be focusing on the following quality attributes:

Modifiability
Testability
Scalability and performance
Availability
Security
Deployability

Modifiability

Many studies show that about 80% of the cost of a typical software system occurs after the initial development and deployment. This shows how important modifiability is to a system's initial architecture.

Modifiability can be defined as the ease with which changes can be made to a system, and the flexibility with which the system adjusts to the changes. It is an important quality attribute, as almost every software system changes over its lifetime—to fix issues, for adding new features, for performance improvements, and so on.

From an architect's perspective, the interest in modifiability is about the following:

Difficulty: The ease with which changes can be made to a system
Cost: In terms of time and resources required to make the changes
Risks: Any risk associated with making changes to the system

Now, what kind of changes are we talking about here? Is it changes to code, changes to deployment, or changes to the entire architecture?

The answer is: it can be at any level.

From an architecture perspective, these changes can generally be captured at the following three levels:

Local: A local change only affects a specific element. The element can be a piece of code such as a function, a class, a module, or a configuration element such as an XML or JSON file. The change does not cascade to any neighboring element or to the rest of the system. Local changes are the easiest to make, and the least risky of all. The changes can usually be quickly validated with local unit tests.
Non-local: These changes involve more than one element. The examples are as follows:
- Modifying a database schema, which then needs to cascade into the model class representing that schema in the application code
- Adding a new configuration parameter in a JSON file, which then needs to be processed by the parser parsing the file and/or the application(s) using the parameter
Non-local changes are more difficult to make than local changes, require careful analysis, and wherever possible, integration tests to avoid code regressions.
Global: These changes either involve architectural changes from top down, or changes to elements at the global level, which cascade down to a significant part of the software system. The examples are as follows:
- Changing a system's architecture from RESTful to messaging (SOAP, XML-RPC, and others) based web services
- Changing a web application controller from Django to an Angular-js based component
- A performance change requirement which needs all data to be preloaded at the frontend to avoid any inline model API calls for an online news application
These changes are the riskiest, and also the costliest, in terms of resources, time and money. An architect needs to carefully vet the different scenarios that may arise from the change, and get his/her team to model them via integration tests. Mocks can be very useful in these kinds of large-scale changes.

The following table shows the relationship between Cost and Risk for the different levels of system modifiability:

Level	Cost	Risk
Local	Low	Low
Non-local	Medium	Medium
Global	High	High

Modifiability at the code level is also directly related to its readability:

"The more readable a code is, the more modifiable it is. Modifiability of a code goes down in proportion to its readability."

The modifiability aspect is also related to the maintainability of the code. A code module which has its elements very tightly coupled would yield to modification much less than a module which has a loosely coupled elements—this is the Coupling aspect of modifiability.

Similarly, a class or module which does not define its role and responsibilities clearly would be more difficult to modify than another one which has well-defined responsibility and functionality. This aspect is called Cohesion of a software module.

The following table shows the relation between Cohesion, Coupling, and Modifiability for an imaginary module A. Assume that the coupling is from this module to another module B:

Cohesion	Coupling	Modifiability
Low	High	Low
Low	Low	Medium
High	High	Medium
High	Low	High

It is pretty clear from the preceding table that having higher Cohesion and lower Coupling is the best scenario for the modifiability of a code module.

Other factors that affect modifiability are as follows:

Size of a module (number of lines of code): Modifiability decreases when size increases.
Number of team members working on a module: Generally, a module becomes less modifiable when a larger number of team members work on the module due to the complexities in merging and maintaining a uniform code base.
External third-party dependencies of a module: The larger the number of external third-party dependencies, the more difficult it is to modify the module. This can be thought of as an extension of the coupling aspect of a module.
Wrong use of the module API: If there are other modules which make use of the private data of a module rather than (correctly) using its public API, it is more difficult to modify the module. It is important to ensure proper usage standards of modules in your organization to avoid such scenarios. This can be thought of as an extreme case of tight Coupling.

Testability

Testability refers to how much a software system is amenable to demonstrating its faults through testing. Testability can also be thought of as how much a software system hides its faults from end users and system integration tests—the more testable a system is, the less it is able to hide its faults.

Testability is also related to how predictable a software system's behavior is. The more predictable a system, the more it allows for repeatable tests, and for developing standard test suites based on a set of input data or criteria. Unpredictable systems are much less amenable to any kind of testing, or, in extreme case, not testable at all.

In software testing, you try to control a system's behavior by, typically, sending it a set of known inputs, and then observing the system for a set of known outputs. Both of these combine to form a testcase. A test suite or test harness, typically, consists of many such test cases.

Test assertions are the techniques that are used to fail a test case when the output of the element under the test does not match the expected output for the given input. These assertions are usually manually coded at specific steps in the test execution stage to check the data values at different steps of the testcase:

Example deployment architecture showing horizontally scaling a web application server

Vertical scalability: Vertical scalability involves adding or removing resources from a single node in a system. This is usually done by adding or removing CPUs or RAM (memory) from a single virtual server in a cluster. The former is called scaling up, and the latter, scaling down. Another kind of scaling up is increasing the capacity of an existing software process in the system—typically, by augmenting its processing power. This is usually done by increasing the number of processes or threads available to an application. Some examples are as follows:

Increasing the capacity of an Nginx server process by increasing its number of worker processes
Increasing the capacity of a PostgreSQL server by increasing its number of maximum connections

Performance

Performance of a system is related to its scalability. Performance of a system can be defined as follows:

"Performance of a computer system is the amount of work accomplished by a system using a given unit of computing resource. Higher the work/unit ratio, higher the performance."

The unit of computing resource to measure performance can be one of the following:

Response time: How much time a function or any unit of execution takes to execute in terms of real time (user time) and clock time (CPU time).
Latency: How much time it takes for a system to get its stimulation, and then provide a response. An example is the time it takes for the request-response loop of a web application to complete, measured from the end-user perspective.
Throughput: The rate at which a system processes its information. A system which has higher performance would usually have a higher throughput, and correspondingly higher scalability. An example is the throughput of an e-commerce website measured as the number of transactions completed per minute.

Performance is closely tied to scalability, especially, vertical scalability. A system that has excellent performance with respect to its memory management would easily scale up vertically by adding more RAM.

Similarly, a system that has multi-threaded workload characteristics and is written optimally for a multicore CPU, would scale up by adding more CPU cores.

Horizontal scalability is thought of as having no direct connection to the performance of a system within its own compute node. However, if a system is written in a way that it doesn't utilize the network effectively, thereby producing network latency issues, it may have a problem scaling horizontally effectively, as the time spent on network latency would offset any gain in scalability obtained by distributing the work.

Some dynamic programming languages such as Python have built-in scalability issues when it comes to scaling up vertically. For example, the Global Interpreter Lock (GIL) of Python (CPython) prevents it from making full use of the available CPU cores for computing by multiple threads.

Availability

Availability refers to the property of readiness of a software system to carry out its operations when the need arises.

Availability of a system is closely related to its reliability. The more reliable a system is, the more available it is.

Another factor which modifies availability is the ability of a system to recover from faults. A system may be very reliable, but if the system is unable to recover either from complete or partial failures of its subsystems, then it may not be able to guarantee availability. This aspect is called recovery.

The availability of a system can be defined as follows:

"Availability of a system is the degree to which the system is in a fully operable state to carry out its functionality when it is called or invoked at random."

Mathematically, this can be expressed as follows:

Availability = MTBF/(MTBF + MTTR)

Take a look at the following terms used in the preceding formula:

MTBF: Mean time between failures
MTTR: Mean time to repair

This is often called the mission capable rate of a system.

Techniques for Availability are closely tied to recovery techniques. This is due to the fact that a system can never be 100% available. Instead, one needs to plan for faults and strategies to recover from faults, which directly determines the availability. These techniques can be classified as follows:

Fault detection: The ability to detect faults and take action helps to avert situations where a system or parts of a system become unavailable completely. Fault detection typically involves steps such as monitoring, heartbeat, and ping/echo messages, which are sent to the nodes in a system, and the response measured to calculate if the nodes are alive, dead, or are in the process of failing.
Fault recovery: Once a fault is detected, the next step is to prepare the system to recover from the fault and bring it to a state where the system can be considered available. Typical tactics used here include Hot/Warm Spares (Active/Passive redundancy), Rollback, Graceful Degradation, and Retry.
Fault prevention: This approach uses active methods to anticipate and prevent faults from occurring so that the system does not have a chance to go to recovery.

Availability of a system is closely tied to the consistency of its data via the CAP theorem which places a theoretical limit on the trade-offs a system can make with respect to consistency versus availability in the event of a network partition. The CAP theorem states that a system can choose between being consistent or being available—typically leading to two broad types of systems, namely, CP (consistent and tolerant to network failures) and AP (available and tolerant to network failures).

Availability is also tied to the system's scalability tactics, performance metrics, and its security. For example, a system that is highly horizontally scalable would have a very high availability, since it allows the load balancer to determine inactive nodes and take them out of the configuration pretty quickly.

A system which, instead, tries to scale up may have to monitor its performance metrics carefully. The system may have availability issues even when the node on which the system is fully available if the software processes are squeezed for system resources, such as CPU time or memory. This is where performance measurements become critical, and the system's load factor needs to be monitored and optimized.

With the increasing popularity of web applications and distributed computing, security is also an aspect that affects availability. It is possible for a malicious hacker to launch remote denial of service attacks on your servers, and if the system is not made foolproof against such attacks, it can lead to a condition where the system becomes unavailable or only partially available.

Security

Security, in the software domain, can be defined as the degree of ability of a system to avoid damage to its data and logic from unauthenticated access, while continuing to provide services to other systems and roles that are properly authenticated.

A security crisis or attack occurs when a system is intentionally compromised with a view to gaining illegal access to it in order to compromise its services, copy, or modify its data, or deny access to its legitimate users.

In modern software systems, the users are tied to specific roles which have exclusive rights to different parts of the system. For example, a typical web application with a database may define the following roles:

user: End user of the system with login and access to his/her private data
dbadmin: Database administrator, who can view, modify, or delete all database data
reports: Report admin, who has admin rights only to those parts of database and code that deal with report generation
admin: Superuser, who has edit rights to the complete system

This way of allocating system control via user roles is called access control. Access control works by associating a user role with certain system privileges, thereby decoupling the actual user login from the rights granted by these privileges.

This principle is the Authorization technique of security.

Another aspect of security is with respect to transactions where each person must validate the actual identity of the other. Public key cryptography, message signing, and so on are common techniques used here. For example, when you sign an e-mail with your GPG or PGP key, you are validating yourself—The sender of this message is really me, Mr. A—to your friend Mr. B on the other side of the e-mail. This principle is the Authentication technique of security.

The other aspects of security are as follows:

Integrity: These techniques are used to ensure that data or information is not tampered with in anyway on its way to the end user. Examples are message hashing, CRC Checksum, and others.
Origin: These techniques are used to assure the end receiver that the origin of the data is exactly the same as where it is purporting to be from. Examples of this are SPF, Sender-ID (for e-mail), Public Key Certificates and Chains (for websites using SSL), and others.
Authenticity: These are the techniques which combine both the Integrity and Origin of a message into one. This ensures that the author of a message cannot deny the contents of the message as well as its origin (himself/herself). This typically uses Digital Certificate Mechanisms.

Deployability

Deployability is one of those quality attributes which is not fundamental to the software. However, in this book, we are interested in this aspect, because it plays a critical role in many aspects of the ecosystem in the Python programming language and its usefulness to the programmer.

Deployability is the degree of ease with which software can be taken from the development to the production environment. It is more of a function of the technical environment, module structures, and programming runtime/languages used in building a system, and has nothing to do with the actual logic or code of the system.

The following are some factors that determine deployability:

Module structures: If your system has its code organized into well-defined modules/projects which compartmentalize the system into easily deployable subunits, the deployment is much easier. On the other hand, if the code is organized into a monolithic project with a single setup step, it would be hard to deploy the code into a multiple node cluster.
Production versus development environment: Having a production environment which is very similar to the structure of the development environment makes deployment an easy task. When the environments are similar, the same set of scripts and toolchains that are used by the developers/DevOps team can be used to deploy the system to a development server as well as a production server with minor changes—mostly in the configuration.
Development ecosystem support: Having a mature tool-chain support for your system runtime, which allows configurations such as dependencies to be automatically established and satisfied, increases deployability. Programming languages such as Python are rich in this kind of support in its development ecosystem, with a rich array of tools available for the DevOps professional to take advantage of.
Standardized configuration: It is a good idea to keep your configuration structures (files, database tables, and others) the same for both developer and production environments. The actual objects or filenames can be different, but if the configuration structures vary widely across both the environments, deployability decreases, as extra work is required to map the configuration of the environment to its structures.
Standardized infrastructure: It is a well-known fact that keeping your deployments to a homogeneous or standardized set of infrastructure greatly aids deployability. For example, if you standardize your frontend application to run on 4 GB RAM, Debian-based 64-bit Linux VPS, then it is easy to automate deployment of such nodes—either using a script, or by using elastic compute approaches of providers such as Amazon—and to keep a standard set of scripts across both development and production environments. On the other hand, if your production deployment consists of heterogeneous infrastructure, say, a mix of Windows and Linux servers with varying capacities and resource specifications, the work typically doubles for each type of infrastructure decreasing deployability.
Use of containers: The user of container software, popularized by the advent of technology such as Docker and Vagrant built on top of Linux containers, has become a recent trend in deploying software on servers. The use of containers allows you to standardize your software, and makes deployability easier by reducing the amount of overhead required to start/stop the nodes, as containers don't come with the overhead of a full virtual machine. This is an interesting trend to watch for.

Filter reviews by

All

Amazon verified reviews

Bhuvneshwar Chouksey Nov 06, 2018

#DeepThought#Coding Skills#Lib Overriding#Giving Confidence to create your own module using existing available functionality with extra features#For R&D Guys #Maturity is very HIGH#Papar Quality Ultimate#All d Best guys for creating better Future.

Amazon Verified review

David Q Mertz May 09, 2017

Anand PIllai touches on a really encyclopedic range of topics with clarity and precision. I'm accustomed to reading books on programming, but this one (as its title fairly indicates) is a different sort of beast. There are definitely very informative chapters on Python programming topics, but the emphasis here is on overall development and engineering practices, and as such serves as a great reference text for software development groups and managers.The many architecture challenges faced by large Python projects are addressed in Anand's book (I confess I've been his colleague and friend for over a decade, hence on first-name terms). It touches on concurrency and parallelism issues, on testing frameworks and best practices, on good documentation practice, on security, and on performance analysis, as well as more topics. It's a long book; but even at such length, any one book must be a guide to the issues that need to be considered rather than in depth documentation of all the relevant tools and libraries. Anand gives you enough to know where to look further, and to evaluate the overall trade-offs among approaches.A challenge in a book like this—which Anand does not wholly overcome—is that any sample code which can be shown on a page or two is automatically somewhat "toy code." As a result, much of the code is somewhat unrealistic to real-world large codebases, and in many cases of necessity represents less than ideal coding choices. Nonetheless, his surrounding text presents well the larger points we are meant to draw from code samples, and these points apply equally, or better, to large projects.

kracekumar May 09, 2017

The book Software Architecture with Python explains various aspects of software architecture like testability, performance, scaling, concurrency and design patterns.The book has ten chapters. The first chapter speaks about different architect roles like solution architect, enterprise architect, technical architect what is the role of an architect and difference between design and architecture. This chapter is theory but worth to know the differences as a software developer.The book covers two lesser spoken topics debugging and code security which I liked. There is very few literature available on debugging. The author has provided real use cases of different debugging tips and tools for Python without picking sides. The book has some good examples on overflow errors in Python.My favorite chapter in the book is 'Writing Applications that scale'. The author explains all the available concurrency primitives like threading, multiprocess, eventlet, twisted, gevent, asyncio, queues, semaphore, locking etc . The author doesn't stop by explaining how to use them but paves the path to figuring out how to profile the code, find out where the bottleneck lies and when to use which concurrency primitives. This chapter is the longest in the book and deluged with examples and insights. The author's approach of using `time` command to measure the performance rather than sticking with wall-clock time gives the developer understanding of where programming is spending most of the time.The book covers vital details on implementing Python Design Patterns and how Python's dynamic nature brings joy while creating the creational, structural and design pattern. The showcased examples teach how Python metaclass works and it's simplicity.The book is indeed a long read and solid one in size and content. Having said that book is pretty hands on and loaded with trivial and non-trivial examples. I won't be surprised if half the book covers the code snippets. The author hasn't shied away from skipping code snippets while explaining any concept. The book introduces a plethora of tools for developing software, and at the same time references required literature and resources.

sh Apr 04, 2018

This book is easy to read and understand, as long as you have an understanding of Python. The example code illustrates the point the author is trying to convey. The main problem, and the reason I deducted 2 stars, is there are a lot of typos. Every 2 or 3 pages, has some sort of typo. There are also some bugs in the code examples (i.e. setting a variable with a value, and then referencing the value instead of the variable name). There is even at least one code example where all of the code is left-justified, so it makes the code technically incorrect without any indentation.

Paul Hoffman Jul 01, 2017

The book is a bit light on usable Python content. It feels like the book started off as "Software Architecture" and then the author plugged in Python at the end.If you're used to well-produced books, this one might set your teeth on edge. The book could use a much better copyedit than what it got, the artwork is amateurish, and the page layout looks like it was chosen to make the book longer.

Software Architecture with Python: Design and architect highly scalable, robust, clean, and high performance applications in Python

What do you get with Print?

Software Architecture with Python

Chapter 1. Principles of Software Architecture

Defining software architecture

Software architecture versus design

Aspects of software architecture

Characteristics of software architecture

An architecture defines a structure

Importance of software architecture

System versus enterprise architecture

Architectural quality attributes

Modifiability

Testability

Performance

Availability

Security

Deployability

Summary

Page 1 of 7

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

About the author

FAQs

Software Architecture with Python: Design and architect highly scalable, robust, clean, and high performance applications in Python

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Defining software architecture

Software architecture versus design

Aspects of software architecture

Characteristics of software architecture

An architecture defines a structure

Importance of software architecture

System versus enterprise architecture

Architectural quality attributes

Modifiability

Testability

Performance

Availability

Security

Deployability

Summary

Page 1 of 7

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

About the author

FAQs

Create a Free Account To Continue Reading

Sign in to activate your 7-day free access