Basic concepts of the microservices architecture

Microservices: Basic Concepts of a Microservices Architecture
______________________________________________________________________________
Study Notes www.SlideShare.net/OxfordCambridge Page 1 of 27
IT Microservices Introduction: 1/2
Basic Concepts of Architecture
Study Notes v.1.0, (Entry Level)
+W Series – Technology Skills For Women.1
1 Men too are allowed to read on, if they wish, as the language style and the document format are universal.

______________________________________________________________________________
1. About “+W Series - Technology Skills for Women”
Study Notes in the field of technology are put together under this category for the following
reasons:
• To encourage girls and ladies, who wish to do so, to stand up and look over the fence
into technology related topics.
• With no apprehension or fear.
• And perhaps consider embracing a career move into a technological path.
• Or simply to broaden their general knowledge; after all IT is already in most aspects of
everyday life.
• No matter the ground for the decision, their skills, their professional strengths, and their
contribution can only be something positive for any technological fields.
Enjoy!

______________________________________________________________________________
2. Table of Contents
1. About “+W Series - Technology Skills for Women” ................................................................2
3. Foreword ...........................................................................................................................................5
4. About this publication....................................................................................................................5
4.1. Overview............................................................................................................................................ 5
4.2. Learning Objectives............................................................................................................................ 5
5. Keywords...........................................................................................................................................6
6. Document Structure .......................................................................................................................7
7. Microservices Architecture ..........................................................................................................8
7.1. What Makes a Microservice? ............................................................................................................. 8
7.1.1. What about Microservices? ........................................................................................................ 8
7.1.2. What exactly is a monolithic service?.......................................................................................... 9
7.1.3. Properties of microservices......................................................................................................... 9
7.1.4. Microservices have a single responsibility ................................................................................. 10
7.2. Topology and Architecture............................................................................................................... 10
7.2.1. Topology of a typical microservices architecture....................................................................... 10
7.2.2. The client layer......................................................................................................................... 11
7.2.3. The API layer ............................................................................................................................ 11
7.2.4. The microservice layer: ............................................................................................................. 12
7.3. Advantages and Disadvantages ........................................................................................................ 12
7.3.1. Advantages of microservices..................................................................................................... 12
7.3.2. Disadvantages of Microservices................................................................................................ 13
7.3.3. Microservice Considerations ..................................................................................................... 13
7.3.4. Microservice Best Practice ........................................................................................................ 13
7.4. Microservice Components................................................................................................................ 14
7.4.1. Overview of microservice components...................................................................................... 14
7.4.2. Client devices............................................................................................................................ 14
7.4.3. Application Program Interface (API).......................................................................................... 15
7.4.4. Microservices............................................................................................................................ 15
7.4.5. Back-end Database................................................................................................................... 15
7.5. Microservice Granularity.................................................................................................................. 15
7.5.1. Atomic Granularity ................................................................................................................... 16
7.5.2. Composite Granularity.............................................................................................................. 17
8. Protocols and Communication ................................................................................................. 18
8.1. Remote Access Protocols (RAC)........................................................................................................ 18
8.1.1. Point-to-Point Protocol (PPP).................................................................................................... 18
8.1.2. PPPoE and PPPoA..................................................................................................................... 20
8.1.3. Point-to-Point Tunneling (PPTP)................................................................................................ 21
8.1.4. Layer Two Tunneling Protocol (L2TP) ........................................................................................ 22
8.2. Microservice Communication........................................................................................................... 23
8.2.1. Inter-Process Communication (IPC) Mechanism overview.......................................................... 23
8.2.2. One-to-one interactions............................................................................................................ 23

______________________________________________________________________________
8.2.3. One-to-many interactions......................................................................................................... 24
8.2.4. IPC technologies ....................................................................................................................... 24
8.2.5. Common communication assumptions and practices................................................................ 24
8.3. Interoperability with Third-party Tools............................................................................................. 25
8.3.1. Kontena.................................................................................................................................... 25
8.3.7. Apache Kafka ........................................................................................................................... 25
8.3.13. Docker...................................................................................................................................... 26
8.3.17. Yipee ........................................................................................................................................ 26
8.3.18. Prometheus.............................................................................................................................. 27

______________________________________________________________________________
3. Foreword
Computing with microservices allows us to run applications with smaller, more focused
services. We can build and run applications without building large monolithic services. In this
publication, we will learn about the building and deploying microservices, microservice
design challenges, microservice design models, and redesigning existing code and services.
4. About this publication
4.1. Overview
In this publication we will learn the basic concepts of the microservices architecture. The
properties surrounding a distributed architecture will be covered. The advantages and
disadvantages of microservices will also be evaluated.
4.2. Learning Objectives
• describe the properties that make up a microservice architecture
• identify the different pieces of a microservice architecture and the function they serve
• discover the advantages and disadvantages of a microservice architecture
• identify the individual components of the microservice topology
• define the level of granularity of microservice components
• describe the properties that make up a microservice architecture
• identify the different pieces of a microservice architecture and the function they serve
• discover the advantages and disadvantages of a microservice architecture
• identify the individual components of the microservice topology
• define the level of granularity of microservice components
• use communication in a microservice architecture
• identify communication protocols
• describe how components of a microservice architecture communicate
• build the API between microservices
• identify compatibility and interoperability issues
• use third-party systems for communication and logging

______________________________________________________________________________
5. Keywords
• Access protocols
• AMQP
• Apache Kafka
• API Gateway
• API layer
• Architecture
• ATM, Asynchronous Transfer Mode
• Avro
• Back End
• C#
• CLI tools
• Client devices
• Client Layer
• Code-to-code communication
• Communication
• Components
• Data sources
• Data validation
• Database
• DEV
• Development cycle
• DevOps
• Docker
• Embedded devices
• Encapsulated microservices
• Frame Relay
• Granularity
• Highly secure
• HTTP API
• HTTP-based REST
• Inputs
• Interoperability
• IP
• IPC, Inter Process Communication,
Mechanism
• IT Systems
• Java
• JSON
• Kontena
• L2TP, Layer Two Tunneling Protocol
• Large applications
• Microservices
• Monolith
• Network
• Outputs
• Point-to-Point Protocol, PPP
• PPPOA, Point-to-Point over
Asynchronous
• PPPoE, Point-to-Point over Ethernet
• PPTP, Point-to-Point Tunneling
• Process
• PROD
• Programming languages
• Prometheus
• Protocol Buffers
• Protocols
• RAC, Remote Access Protocol
• RESful
• Server
• STOMP
• Streaming sources
• Synchronous
• Thrift
• Topology
• Web Client
• Web services
• WebSocket
• XML
• Yipee

______________________________________________________________________________
6. Document Structure
Part 1: Microservices Architecture
• What Makes a Microservice?
• Topology and Architecture
• Advantages and Disadvantages
• Microservice Components
• Microservice Granularity
Part 2: Protocols and Communication
• Remote Access Protocols (RAC)
• Microservice Communication
• Interoperability with Third-party Tools

______________________________________________________________________________
7. Microservices Architecture
7.1. What Makes a Microservice?
After reading this section, we should be able to describe the properties that make up a microservice
architecture.
7.1.1. What about Microservices?
7.1.1.1. Like many things in IT, the concepts are easy to understand. The hardest part
is always in the details. Microservices in general is an architecture that basically
takes a large service (called a monolith) and breaks it down into small sharable
components.
7.1.1.2. In a traditional monolith design, all the functionality is placed into a single
process.
7.1.1.2.1. This process is then instantiated over multiple servers that uses process:
Monolithic Application Approach.
7.1.1.2.2. This results in code being instantiated across servers whether the code is
run or not.
7.1.1.3. A microservices architecture will break this down into smaller chunks of code
that is instantiated across servers as needed.

______________________________________________________________________________
7.1.2. What exactly is a monolithic service?
7.1.2.1. You probably already use monolithic services. You operate this kind of
service from your application, for example, making a database connection and
writing and executing a SQL statement, and perhaps processing a result set.
7.1.2.2. All the functionality here takes place in one large service which works, but a
microservices architecture would break each individual functionality into its own
small service called microservice: Microservices Approach.
7.1.2.3. The application then uses several microservices instead of a larger monolith
service. Typically, the application would call an API that would act as a
controller, a traffic handler per say. This API would conceivably call an
individual API for each microservice that needs to be used
7.1.2.4. The concept is straightforward and easy to understand, but as we can imagine
it's not the perpetual silver bullet. As a matter of fact, it's not even
recommended for most organizations. As IT professionals, it is up to us to
determine if we can get true benefits from using microservices for our
organisation.
7.1.3. Properties of microservices.
7.1.3.1. First, each part of microservices should be able to be replaced independently
from each other.
7.1.3.2. Also, microservices are built around business needs and functionalities.
7.1.3.3. Microservices also have smart endpoints and dumb pipes. Pipes don't know
what they are doing, only where they are going.
7.1.3.4. Next, components act individually avoiding the ESB model (enterprise service
bus implements a communication system between mutually interacting
software applications in a service-oriented architecture or SOA). Busses are
bad in a microservices architecture.
7.1.3.5. Furthermore, database management is decentralized, and infrastructure is
automated when using microservices.

______________________________________________________________________________
7.1.3.6. Moreover, and true to DevOps, microservices are continuously delivered.
7.1.4. Microservices have a single responsibility
7.1.4.1. Instead of a monolith having code to do everything, microservices have a single
responsibility. They only do one thing.
7.1.4.2. Microservices are object oriented, like most other things that we write. And
instead of having a bunch of code, microservices are small. They are only
designed and built to do one thing.
7.1.4.3. Microservices are also monitored. This monitoring and logging are part of the
deal when using microservices.
7.1.4.4. A monolithic service architecture does not attempt to network each service.
This is not the case in a microservices architecture.
7.1.4.5. Microservices are clustered. Each small piece acts independently of each
other, and each piece is deployed on the cluster.
7.2. Topology and Architecture
After reading this section, we should be able to identify the different pieces of a microservice
architecture and the function they serve.
7.2.1. Topology of a typical microservices architecture
7.2.1.1. Like in most cases, there is more than one design pattern.
7.2.1.2. However, here, let us take a peek at a typical implementation of a
microservices architecture.
7.2.1.3. Here we have three clients: a web client, an Internet of Things (IoT), and a
mobile client. We have a bunch of clients for the application.

______________________________________________________________________________
7.2.1.4. They access the API gateway using different protocols: Web Client uses the
JSON protocol, IoT uses the Notification protocol, and Mobile Client uses the
HTTP, WebSocket protocol to access the API Gateway.
7.2.1.5. The API then directs processing to the correct microservice. All of this is logged
and has a database component.
So let's take a closer look at each layer in this topology.
7.2.2. The client layer
7.2.2.1. This layer can be about anything – Internet of Things, web, mobile, anything
that needs to use the application.
7.2.2.2. The client layer is still dumb, as it should be. It knows nothing about services
versus microservices.
7.2.2.3. The methods that client layer uses to connect does not change. It still interfaces
with the API layer as it always did. And it works with existing protocols, as it
always did as well.
7.2.2.4. Microservices provide a highly reliable and a highly secure way for the client
layer to connect to the application and can be written in a variety of
programming languages. [API Gateway.]
7.2.3. The API layer
7.2.3.1. There is not much radical changes and as always, the API layer still exists on
the server side.
7.2.3.2. But there are some notable differences however.
7.2.3.3. First it must be modified to locate individual microservices.
Microservice Layer
Small pieces of
software that do only
one thing
Know about each
other’s existence but
not what they do
Small pieces of
software can be on
different platforms
Small pieces of
software receive
input from an API
Small pieces of
software receive
input from each
other
Small pieces can be
replaced individually
Copyright OxfordCambridge.Org, 2019

______________________________________________________________________________
7.2.3.4. The API also now acts as a controller, forwarding processing to the correct
code: directing requests to encapsulated microservices.
7.2.3.5. The API is also more standardized and now has a standard API and APIs to
redirect input to microservices.
7.2.3.6. The API is also highly secure, and like the client layer it can be in a variety of
programming languages.
7.2.4. The microservice layer:
7.2.4.1. Instead of having a monolithic service, there are small pieces of software that
only do one thing like pieces in a puzzle. Microservices know about each
other's existence but not what each other does.
7.2.4.2. Functionality is encapsulated and accessed through an API. Each microservice
can be on a different platform and even written in different languages.
7.2.4.3. They all do have the same properties in common. Also, they all receive input
from the API, from each other, or from the back-end. And they could be
individually replaced, completely independent of each other.
7.2.4.4. Last, there is the back-end which still knows nothing of the API and the client
layer.
7.2.4.5. The back-end is still encapsulated and could be many things. It can be a
database, a web service, or any other destination.
7.2.4.6. Back-ends know only about the microservice it communicates with, either with
inbound or outbound messages.
7.2.4.7. Also, back-ends can communicate back to the API via a microservice only and
no other mechanism. All of this activity and messaging is logged. Therefore, the
back-end should have messaging and logging capability.
7.2.4.8. Because the back-end may be engineered to communicate with monoliths, it
may need to be modified to communicate with microservices, then.
7.3. Advantages and Disadvantages
After reading this section, we should be able to discover the advantages and disadvantages of a
microservice architecture.
7.3.1. Advantages of microservices
There are several advantages of using microservices.
7.3.1.1. First there is flexibility. We are not pinned down into a language or even the
framework. Therefore, we have the ability to choose frameworks and our tools.
7.3.1.2. Microservices are also loosely coupled and can get swapped out easily. As
such, individual microservices are interchangeable. This makes them scale
better than monolithic services.
7.3.1.3. Since microservices are smaller and contain less code, they are easier to
debug since they only do one thing.
7.3.1.4. They also support continuous integration. It's common to deploy microservices
from applications like Jenkins (an open source automation server written in
Java. Jenkins helps to automate the non-human part of the software
development process, with continuous integration and facilitating technical
aspects of continuous delivery).

______________________________________________________________________________
7.3.1.5. Microservices are also Agile and so far as development can be shared across
feature teams.
7.3.2. Disadvantages of Microservices
Microservices also has its own microservices. The microservices architecture is not recommended
for most applications.
7.3.2.1. First distributed architectures are complicated. It may be difficult to design how
microservice will even work within our organization.
7.3.2.2. Also, refactoring monolithic services will be challenging. Database transactions
and threading will become major issues.
7.3.2.3. When developing microservices along with an existing monolith, parallel paths
may be difficult to implement.
7.3.2.4. There is also the issue of who will own the microservice architecture when it is
deployed. Also, who is going to support it? And how will the microservices be
deployed will all become issues.
7.3.3. Microservice Considerations
There are design considerations for microservices. These are not good or bad, just things that need
to be considered.
7.3.3.1. A microservice architecture brings increased complexity as there are more
moving parts.
7.3.3.2. Also, with the fact that there are more moving parts and more components in
general, response time can be an issue. Thus, network congestion and latency
will have to be dealt with.
7.3.3.3. Data consistency will be an issue as well because data will be passed around
from microservice to microservice. This can lead to fault tolerance and
resiliency issues. This separation of processing may cause issues in
diagnosing problems.
7.3.3.4. Versioning may also become an issue as microservices are continuously
deployed.
7.3.4. Microservice Best Practice
7.3.4.1. Since versioning can be an issue, it's recommended that we use common
source control for all services.
7.3.4.2. And as there may be several versions in the pipeline, it's a best practice to try
to mimic PROD in DEV. This of course, infers to good coding practices such as
pushing working code to the main branch often.
7.3.4.3. Also, use the DevOps approach to a short development cycle and adhere to the
rule of releasing less and releasing fast.
7.3.4.4. Furthermore, beware of shared libraries. Although they are needed, they are
hard to update and very hard to test.
7.3.4.5. And finally, keep our services simple.

______________________________________________________________________________
7.4. Microservice Components
After reading this section, we should be able to identify the individual components of the
microservice topology.
7.4.1. Overview of microservice components
7.4.1.1. The components in a microservice design lend itself to a very modular design.
Components are meant to be small and interchangeable.
7.4.1.2. Some components can never change. For example, client devices are fixed
and can never really be controlled by us.
7.4.1.3. One thing that we need to know is that we will need to support more and more
of them as users adopt them.
7.4.1.4. Each of these client devices communicate with many small microservices
through an API. Each of these services collectively make up the application and
communicate with the back-end where data is persisted. Monitoring and
logging are also part of the process.
7.4.2. Client devices
7.4.2.1. Client devices are proliferating faster than ever and w must support all of them.
7.4.2.2. The good news is that there are standard protocols in which the client devices
communicate with the API layer.
7.4.2.3. Traditional web browsers use to be by far the most used client device. Once
accounting for almost a 100% of the front-end traffic for our applications.
7.4.2.4. Now times have changed and the technologies have evolved. Therefore,
mobile devices such as smartphones and tablets need to be supported.

______________________________________________________________________________
7.4.2.5. In addition, client devices can now be web services, embedded devices,
streaming sources, and even other data sources that we may not have even
thought of.
7.4.3. Application Program Interface (API)
7.4.3.1. The API component has few unique features. First, they might not even know
about where a service may be, if it exists at all.
7.4.3.2. An API can be used to discover services. This discovery and redirection makes
the API act as a traffic policeman/policewoman.
7.4.3.3. This communication makes the API components very message-oriented as
each API is constantly processing inbound and outbound messages.
7.4.3.4. API components don't even need to be on the same operating system. They
are truly multiplatform and multilingual. Common development languages
include Java and C#.
7.4.3.5. Also, an API interfaces with other APIs but never directly with microservices.
7.4.4. Microservices
7.4.4.1. Unlike the monoliths they are replacing, microservices are small. And each
microservice does not do much. And they have a very small footprint and are
lightweight.
7.4.4.2. They are entirely independent of each other and each microservice runs in its
own process. They require zero functionality from other microservices making
them self-contained.
7.4.4.3. Like pieces in a puzzle, each microservice makes up the entire system. And
again, each piece is designed independently as well as deployed, and run
without the help of other microservices. [Database – Back-end.]
7.4.5. Back-end Database
7.4.5.1. The last components in a microservice system are the back-end pieces. And
these pieces are used for data persistence and usually are a SQL or cloud-
based NoSQL database.
7.4.5.2. Such back-end pieces do not talk to each other, instead directly to the API
which acts as a buffer.
7.4.5.3. The back-end never communicates directly with microservices. This makes the
back-end encapsulated as it never exposes its functionality. This is where the
data validation and the cleansing take place.
7.4.5.4. Also, the back-end does not necessarily have to be a traditional database.
7.5. Microservice Granularity
After reading this section, we should be able to define the level of granularity of microservice
components.

______________________________________________________________________________
7.5.1. Atomic Granularity
7.5.1.1. Microservices have a property commonly referred to as granularity. Granularity
defines how exact or how fine the grain of a service is.
7.5.1.2. A fine grain is more focused and it contains less functionality of a larger grain,
which has more functionality within.
7.5.1.3. Atomic granularity refers to a single blob of code that contains all the
functionality for a microservice. Everything goes into it, and everything comes
out of it on route to the message's destination.
7.5.1.4. It's called Atomic, as its one piece of code. The functionality is not divided into
smaller units.
7.5.1.5. As to the properties of atomic granularity, instead of functionality being
subdivided, functionality exists in one big single blob of code.
7.5.1.6. The functionality of atomic granularity is hidden and it can only be accessed
through a set of defined interfaces, with two or three inputs and outputs. In
many cases, there will be more and multiple input and output interfaces.
Monolithic SOA
Single Unit Coarse-grained
Microservices
Coarse-grained
Monolithic vs. SOA vs. Microservices
© OxfordCambridge.Org, 2019

______________________________________________________________________________
7.5.1.7. This design is very similar to a service-based architecture and the code runs
very much like a service.
7.5.1.8. Each atomic component runs in its own thread; and it also runs in a separate
process independent from other instances. In this way, each of the components
encapsulates functionality from each other.
7.5.2. Composite Granularity.
7.5.2.1. The functionality is broken down into more discrete units, in order to make the
design more modular and flexible, where each unit is independent.
7.5.2.2. This design looks at the functionality of a service and the functionality
decomposes it into smaller units, with each unit doing only one thing.
7.5.2.3. There are still many inputs and outputs, however each message may take an
entirely different path through this design, with touching each microservice as
it's needed, while bypassing the rest.
7.5.2.4. Such design is also more complicated and has all the drawbacks of code-to-
code communication that monolithic designs tend to avoid.
7.5.2.5. This composite pattern is very useful for large applications that need to be
broken down into smaller units.
7.5.2.6. When taking a closer look at the architecture of a composite granular
component, we notice the functionality is encapsulated and has an outer
service with a set of interfaces. And these interfaces process the incoming
message.
7.5.2.7. From there, the component contains one or more inner components. These
inner components contain the actual code for the functionality of the
microservice.
7.5.2.8. Each component that has a granular design runs as a separate process by
default. None shares anything, and each inner component runs in a separate
thread.
7.5.2.9. This design offers greater opportunities for reuse over atomic granularity.
Comp1 Comp2
Comp4Comp3
Inputs
Inputs
Inputs
Outputs
Outputs
Outputs
Composite Microservices
Copyright OxfordCambridge.Org 2019

______________________________________________________________________________
8. Protocols and Communication
8.1. Remote Access Protocols (RAC)
After reading this section, we should be able to identify communication protocols (set of
communication rules) such as RAC.
We will look at some communication protocols that can be used when using microservices.
8.1.1. Point-to-Point Protocol (PPP)
8.1.1.1. PPP is an acronym for Point to Point Protocol. It is a member of the TCP/IP
suite of network protocols. PPP is an extension to TCP/IP that adds two
additional sets of functionalities:
8.1.1.1.1. It can transmit TCP/IP packets over a serial link.
8.1.1.1.2. It has login security facility.
8.1.1.2. TCP/IP by itself cannot be transmitted over a serial link. This makes it
unsuitable for WANs (Wide Area Networks). To make TCP/IP work over these
serial links, it was necessary to create a protocol that could transmit TCP/IP
packets over serial lines. The two protocols that do this are:
8.1.1.2.1. SLIP (Serial Line Internet Protocol)
8.1.1.2.2. PPP
8.1.1.3. When serial links that are part of the public telephone system are used, care
must be taken to ensure the authenticity of all communications. To this end
PPP incorporates user name and password security.
8.1.1.4. Therefore, a router or server receiving a request via PPP where the origin of
the request is not secure, would require authentication.
8.1.1.5. This authentication is part of PPP. Because of its ability to route TCP/IP
packets over serial links and its authentication capabilities, PPP is generally
used by Internet Service Providers (ISPs) to allow dial-up users to connect to
the Internet.
8.1.1.6. PPP is an old but still very popular protocol. It’s a Data Link Layer protocol
operating over a point-to-point network link. This is a link connecting two
communicating peers at the link level.

______________________________________________________________________________
8.1.1.7. Each peer being at the opposite end-point of each link. In the past PPP was the
protocol of choice for connecting home users to their Internet Service Provider
(ISP)'s over a dial-up Internet connection.
8.1.1.8. PPP is used in synchronous and asynchronous connections. And it can
dynamically configure and test remote network connections.
8.1.1.9. PPP was often used by clients to connect to networks and over the Internet.
8.1.1.10. It's a safe protocol providing encryption for passwords and secure
authentication of remote users.

______________________________________________________________________________
8.1.2. PPPoE and PPPoA
8.1.2.1. A Point-to-Point Protocol over Ethernet (PPPoE) and Point-to-Point Protocol
over Asynchronous Transfer Mode (PPPoA) are both more recent PPP
implementations.
8.1.2.2. Such Internet connection types are used by Digital Subscriber Lines or DSL
ISPs to establish an Internet connection for end-users.
8.1.2.3. PPP, which was designed for serial communications, has now been adapted to
Ethernet, and is appropriately called PPP over Ethernet (PPPoE). Since PPP
was designed to do things that were either impossible or unnecessary with
Ethernet, users are often confused as to why one would want to use PPP over
Ethernet at all.
8.1.2.4. PPP over Ethernet (PPPoE) brings this sort of functionality to ISPs that do not
use serial links to connect their users. Serial ISPs already use PPP over
modem communications. DSL providers on the other hand use Ethernet, not
serial communications. Because of this, many require the added functionality of
PPPoE, which allows them to secure communications through the use of User
Logins and have the ability to measure the volume of traffic each user
generates.

______________________________________________________________________________
8.1.2.5. PPPoA is ever so slightly faster than PPPoE, and it does avoid the Maximum
Transfer Unit (MTU issue).
8.1.2.6. The MTU for PPPoA is at 1,500 bytes and MTU for PPPoE is 1,492 bytes.
8.1.2.7. Point-to-Point Protocol over ATM (PPPoA) is also a network protocol but this
time, it is for encapsulating frames inside AAL5 or ATM Adaption Layer 5.
8.1.3. Point-to-Point Tunneling (PPTP)
8.1.3.1. This is a Microsoft VPN Layer 2 protocol and it increases the security of PPP by
providing tunneling and data encryption for PPP packets.
8.1.3.2. PPTP is a protocol (set of communication rules) that allows corporations to
extend their own corporate network through private "tunnels" over the public
Internet.
8.1.3.3. Effectively, a corporation uses a wide-area network as a single large local area
network. A company no longer needs to lease its own lines for wide-area
communication but can securely use the public networks. This kind of
interconnection is known as a virtual private network (VPN).

______________________________________________________________________________
8.1.3.4. PPTP uses the same authentication types as PPP and is a common VPN
method among older Windows clients such as LINQ query provider.
8.1.3.5. However, PPTP has serious vulnerabilities and is no longer recommended by
Microsoft.
8.1.3.6. Because it is not secure, PPTP is considered dead by many. It can easily be
cracked by the most amateur hackers and should no longer be considered for
use.
8.1.3.7. Therefore, it is best to consider other protocols instead.
8.1.4. Layer Two Tunneling Protocol (L2TP)
8.1.4.1. Layer Two Tunneling Protocol (L2TP) is an extension of the Point-to-Point
Tunneling Protocol (PPTP) used by an Internet service provider (ISP) to enable
the operation of a virtual private network (VPN) over the Internet.
8.1.4.2. L2TP merges the best features of two other tunneling protocols: PPTP from
Microsoft and L2F from Cisco Systems.
8.1.4.3. The two main components that make up L2TP are the L2TP Access
Concentrator (LAC), which is the device that physically terminates a call and
the L2TP Network Server (LNS), which is the device that terminates and
possibly authenticates the PPP stream.
8.1.4.4. A benefit of L2TP is that it saves the dial-up cost and the overhead for any user
that's willing to remotely connecting with a site office.
8.1.4.5. L2TP is also known as virtual dial-up protocol. This is because of the use of the
Point-to-Point extension over the Internet.
8.1.4.6. L2TP enables the tunneling of PPP sessions and tunneling across a variety of
network protocols such as IP, Frame Relay, and Asynchronous Transfer Mode
(ATM). It's used to support virtual private networks and does not provide any
data encryption.

______________________________________________________________________________
8.2. Microservice Communication
After reading this section, we should be able to describe how components of a microservice
architecture communicate.
8.2.1. Inter-Process Communication (IPC) Mechanism overview
8.2.1.1. The IPC refers to operating system's mechanisms and techniques where
multiple threads in many or one processes need to exchange data with the
other, and they are divided into dimensions.
8.2.1.2. The first dimension:
8.2.1.2.1. With one-to-one, where each client request is processed by exactly one
service instance.
8.2.1.2.2. Then we have one-to-many, where each request is processed by multiple
service instances.
8.2.1.3. Next there is the second dimension:
8.2.1.3.1. First there is Synchronous, where the client expects a timely response from
the service and may even block while it waits.
8.2.1.3.2. Second we have Asynchronous, where the client will not block while
waiting for a response, and the response, if any, isn't necessarily sent
immediately.
8.2.2. One-to-one interactions
8.2.2.1. The first interaction is the request/response:
8.2.2.1.1. In this interaction, a client makes a request to a service, then it waits for a
response.
8.2.2.1.2. Then the client expects the response to arrive. In a thread-based application,
the thread that makes the request may even block while waiting.
8.2.2.2. The second interaction is called a notification or a one-way request:

______________________________________________________________________________
8.2.2.2.1. The client sends a request to a service, but no reply is sent or even
expected.
8.2.2.3. And the final one-to-one interaction is a request/async response:
8.2.2.3.1. In this interaction, the client sends a request to a service that replies
asynchronously.
8.2.2.3.2. The client does not block while waiting and is designed with the assumption
that the response may not arrive anytime soon.
8.2.3. One-to-many interactions.
8.2.3.1. This type of interaction is divided into two sections.
8.2.3.2. Publish/subscribe interaction:
8.2.3.2.1. The client publishes a notification message, which is consumed by zero –
none – or more interested services.
8.2.3.3. Publish/async responses interaction:
8.2.3.3.1. In this interaction the client publishes a request message and then waits for
responses from interested services.
8.2.4. IPC technologies
8.2.4.1. First, we have HTTP-based REST or Thrift, AMQP or STOMP, JSON or XML,
and Avro or Protocol Buffers.
8.2.4.2. HTTP and JSON or XML are primarily used because they are platform and
language independent. The HTTP API allows for a RESTful architecture, which
is a scalable model for developing distributed systems.
8.2.4.3. Two of the most important reasons to use AMQP are reliability and
interoperability. STOMP is text-based, making it analogous or more analogous
to HTTP.
8.2.4.4. Apache Avro is a reliable data serialization system and provides a very useful,
compact, and fast binary data format.
8.2.4.5. And Protocol Buffers is another IPC Technology.
8.2.5. Common communication assumptions and practices.
8.2.5.1. To start with, all microservices must communicate using an IPC.
8.2.5.2. With that in mind, there are many different considerations to take into account.
8.2.5.2.1. We should consider how the services interact and what is the interaction? Is
it one-to-one, one to-many, or none of the above?
8.2.5.2.2. Also, we should consider how to specify the API for each service, while
keeping in mind that the API design will center around the business
functionality of the microservice itself.
8.2.5.2.3. Similarly, we should consider how to evolve the API. What is the migration
plan? How will the APIs be deployed?
8.2.5.2.4. And finally, also consider how to handle partial failure. Success is not all or
nothing. So, we should also plan for the nothing part too.

______________________________________________________________________________
8.3. Interoperability with Third-party Tools
After reading this section, we should be able to identify compatibility and interoperability issues.
8.3.1. Kontena
8.3.2. Kontena is a leading third-party tools for microservice development and
deployment.
8.3.3. It is said to be a developer-friendly container and microservices platform, and it
contains all we need to run our containers in production.
8.3.4. Kontena monitoring functionality is performed for dashboard but Kontena does
contain powerful CLI tools for monitoring and management.
8.3.5. It's heterogeneous and can be deployed on any infrastructure, and could be used
together with Kontena Cloud.
8.3.6. It's also 100% open source under the Apache 2.0 license.
8.3.7. Apache Kafka
8.3.8. It’s an open-source stream processing software platform written in Java and Scala.
8.3.9. The project aims to provide us with a unified, high-throughput, low-latency platform
for handling real-time data feeds.
8.3.10. Kafka is an open-source distributed message broker originally developed by
LinkedIn, but it's currently maintained by the Apache Software Foundation.
8.3.11. The fundamental job of Kafka is to write messages to a log on disk.
8.3.12. Finally, at the core of Kafka there are queues, and queues in Kafka are called
topics.

______________________________________________________________________________
8.3.13. Docker
8.3.14. It’s another product that we can leverage for our microservice development and
deployment.
8.3.15. Docker takes our application and the environment it runs in and builds it into a
container. This container will have everything within it our application needs
including microservices, and this container platform is used to build, secure, and
manage applications.
8.3.16. It's open source and multiarchitecture operations at scale. Thus, Docker is built with
open source technology and can easily be integrated into existing environments. As
a popular DevOps tool, Docker is conducive to rapidly changing environments.
8.3.17. Yipee
8.3.17.1. Designing and building microservice applications and using containers can be
extremely cumbersome and complex.
8.3.17.2. For that reason, Yipee can help DevOps teams with the creation, collaboration,
and the orchestration of microservices.
8.3.17.3. Like most DevOps tools, Yipee offers flexibility in the development and the
deployment as well as orchestration flexibility.
8.3.17.4. It has also a robust modeler that allows developing teams to visualize
applications and provides a real visual representation of networks and storage
systems.
8.3.17.5. As well, Yipee can be used for DevOps teams to collaborate and share ideas
and applications.

______________________________________________________________________________
8.3.18. Prometheus
8.3.18.1. Prometheus is from the open-source community and is a monitoring system
and contains a dimensional data model.
8.3.18.2. It also contains alerts and a flexible query language, and events are monitored
in real-time.
8.3.18.3. Prometheus was designed for many nodes and boasts a convenient, graphical
interface and supports real-time based tracking. Its new and approved query
language makes it easy to gather and disseminate monitoring information very
quickly.

Basic concepts of the microservices architecture

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Marius FAILLOT DEVARRE

Mehr von Marius FAILLOT DEVARRE (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Basic concepts of the microservices architecture