Edition 0 Updated to asp. Net core 0

Remote data sources and cache
tools like Azure SQL Database, Azure Cosmos DB, or a remote cache 
like Redis can be used in containerized applications the same way they are used when developing 
without containers. This is a proven way to store business application data. 
Azure Storage.
Business data usually will need to be placed in external resources or databases, like 
Azure Storage. Azure Storage, in concrete, provides the following services in the cloud: 
•
Blob storage stores unstructured object data. A blob can be any type of text or binary data, such 
as document or media files (images, audio, and video files). Blob storage is also referred to as 
Object storage. 

---

25 
CHAPTER 3 | Architecting container and microservice-based applications 
•
File storage offers shared storage for legacy applications using standard SMB protocol. Azure 
virtual machines and cloud services can share file data across application components via 
mounted shares. On-premises applications can access file data in a share via the File service 
REST API. 
•
Table storage stores structured datasets. Table storage is a NoSQL key-attribute data store, 
which allows rapid development and fast access to large quantities of data. 
Relational databases and NoSQL databases.
There are many choices for external databases, from 
relational databases like SQL Server, PostgreSQL, Oracle, or NoSQL databases like Azure Cosmos DB, 
MongoDB, etc. These databases are not going to be explained as part of this guide since they are in a 
completely different subject. 
Service-oriented architecture 
Service-oriented architecture (SOA) was an overused term and has meant different things to different 
people. But as a common denominator, SOA means that you structure your application by 
decomposing it into multiple services (most commonly as HTTP services) that can be classified as 
different types like subsystems or tiers. 
Those services can now be deployed as Docker containers, which solves deployment issues, because 
all the dependencies are included in the container image. However, when you need to scale up SOA 
applications, you might have scalability a
nd availability challenges if you’re deploying based on single 
Docker hosts. This is where Docker clustering software or an orchestrator can help you, as explained in 
later sections where deployment approaches for microservices are described. 
Docker containers are useful (but not required) for both traditional service-oriented architectures and 
the more advanced microservices architectures. 
Microservices derive from SOA, but SOA is different from microservices architecture. Features like 
large central brokers, central orchestrators at the organization level, and the 
Enterprise Service Bus 
(ESB)
 are typical in SOA. But in most cases, these are anti-patterns in the microservice community. In 
fact, some people argue that “The microservice architecture is SOA done right.”
This guide focuses on microservices, because a SOA approach is less prescriptive than the 
requirements and techniques used in a microservice architecture. If you know how to build a 
microservice-based application, you also know how to build a simpler service-oriented application. 
Microservices architecture 
As the name implies, a microservices architecture is an approach to building a server application as a 
set of small services. That means a microservices architecture is mainly oriented to the back-end, 
although the approach is also being used for the front end. Each service runs in its own process and 
communicates with other processes using protocols such as HTTP/HTTPS, WebSockets, or 
AMQP
. 
Each microservice implements a specific end-to-end domain or business capability within a certain 
context boundary, and each must be developed autonomously and be deployable independently. 
Finally, each microservice should own its related domain data model and domain logic (sovereignty 

---

26 
CHAPTER 3 | Architecting container and microservice-based applications 
and decentralized data management) and could be based on different data storage technologies 
(SQL, NoSQL) and different programming languages. 
What size should a microservice be? When developing a microservice, size shouldn’t be the important 
point. Instead, the important point should be to create loosely coupled services so you have 
autonomy of development, deployment, and scale, for each service. Of course, when identifying and 
designing microservices, you should try to make them as small as possible as long as you don’t have 
too many direct dependencies with other microservices. More important than the size of the 
microservice is the internal cohesion it must have and its independence from other services. 
Why a microservices architecture? In short, it provides long-term agility. Microservices enable better 
maintainability in complex, large, and highly-scalable systems by letting you create applications based 
on many independently deployable services that each have granular and autonomous lifecycles. 
As an additional benefit, microservices can scale out independently. Instead of having a single 
monolithic application that you must scale out as a unit, you can instead scale out specific 
microservices. That way, you can scale just the functional area that needs more processing power or 
network bandwidth to support demand, rather than scaling out other areas of the application that 
don’t need to be scaled. That means cost savings because you need less hardware.
Figure 4-6. Monolithic deployment versus the microservices approach 
As Figure 4-6 shows, in the traditional monolithic approach, the application scales by cloning the 
whole app in several servers/VM. In the microservices approach, functionality is segregated in smaller 
services, so each service can scale independently. The microservices approach allows agile changes 
and rapid iteration of each microservice, because you can change specific, small areas of complex, 
large, and scalable applications. 
Architecting fine-grained microservices-based applications enables continuous integration and 
continuous delivery practices. It also accelerates delivery of new functions into the application. Fine-
grained composition of applications also allows you to run and test microservices in isolation, and to 

---

27 
CHAPTER 3 | Architecting container and microservice-based applications 
evolve them autonomously while maintaining clear contracts between them. As long as you don’t 
change the interfaces or contracts, you can change the internal implementation of any microservice or 
add new functionality without breaking other microservices. 
The following are important aspects to enable success in going into production with a microservices-
based system: 
•
Monitoring and health checks of the services and infrastructure. 
•
Scalable infrastructure for the services (that is, cloud and orchestrators). 
•
Security design and implementation at multiple levels: authentication, authorization, secrets 
management, secure communication, etc. 
•
Rapid application delivery, usually with different teams focusing on different microservices. 
•
DevOps and CI/CD practices and infrastructure. 
Of these, only the first three are covered or introduced in this guide. The last two points, which are 
related to application lifecycle, are covered in the additional 
Containerized Docker Application 
Lifecycle with Microsoft Platform and Tools
 e-book.