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.
Dostları ilə paylaş: |