Fr

ee

Microservices has sprung up over the last few years

as a superior approach to monolithic architecture. It
has become the preferred way of creating enterprise
applications. Through this book, you'll discover the
power of Node.js by writing fast and light microservices
ready to ship in small Docker containers, making
deployment and scaling quite enjoyable.
You will be introduced to tools such as Seneca and
PM2 to implement microservices with Node.js. We will
help you understand and avoid common pitfalls faced
while working with microservices. You will also learn
to control your applications by getting to know the best
tools for logging and monitoring.
Upon completion of this book, you will understand the
process of building high-quality microservices with a
good test coverage, as well as the concepts of Node.js
that are required to build microservices.

Who this book is written for

Understand Node.js modules and get to

know the best practices when working
with microservices

Re-architecture of an existing monolithic

system into microservice-oriented software

Build robust and scalable microservices using

Seneca and Node.js

Test the microservices in isolation to create a

solid system

Deploy and manage microservices using PM2

Monitor the health of a microservice (CPU,

memory, and I/O)

$ 39.99 US
25.99 UK

community experience distilled

P U B L I S H I N G

David Gonzalez

This book is for Node.js developers with basic

server-side development knowledge, but no knowledge
of implementing microservices in Node.js applications.
It will also be useful for developers who use other
languages such as Java or C#.

What you will learn from this book

Developing Microservices with Node.js

Developing Microservices
with Node.js

pl

C o m m u n i t y

E x p e r i e n c e

D i s t i l l e d

Developing Microservices
with Node.js
Learn to develop efficient and scalable microservices for
server-side programming in Node.js using this hands-on guide

Prices do not include

local sales tax or VAT
where applicable

Visit www.PacktPub.com for books, eBooks,

code, downloads, and PacktLib.

Sa
m

David Gonzalez

In this package, you will find:

The author biography

A preview chapter from the book, Chapter 1 'Microservices Architecture'
A synopsis of the books content
More information on Developing Microservices with Node.js

About the Author

David Gonzalez is a language-agnostic software engineer working in financial

services for a number of years, trying to find solutions for the right level of
abstraction and learning how to get the right balance between too concrete
and too abstract.

He studied in Spain, but soon moved to the wider and more interesting market
of Dublin, where he has been living since 2011. David is currently working as an
independent consultant in the FinTech sector. The URL to his Linkedin account is
https://ie.linkedin.com/in/david-gonzalez-737b7383.
He loves experimenting with new technologies and paradigms in order to get the
broader picture of the complex world of software development.

Preface
This book is a hands-on guide to start writing microservices using Node.js and
the most modern frameworks, especially Seneca and PM2. In the chapters, we will
discuss how to design, build, test, and deploy microservices using the best practices.
We will also discuss a valuable lesson: how to make the right level of compromise
in order to avoid over-designing and get the business requirements aligned with the
technical solutions.

What this book covers

Chapter 1, Microservices Architecture, discusses the pros and cons of microservicesoriented architectures. It will be the foundation for the rest of the book.
Chapter 2, Microservices in Node.js Seneca and PM2 Alternatives, introduces Node.js,
Seneca, and PM2. In it, we will discuss the structure of a Node.js application and how
to run it using PM2. We will also dive into a few alternatives to Seneca and PM2.
Chapter 3, From the Monolith to Microservices, covers how to tackle the organic growth
(unplanned software changes) using microservices. We will also talk about how to
split a monolithic application into microservices.
Chapter 4, Writing Your First Microservice in Node.js, explains how to write our
first microservice.
Chapter 5, Security and Traceability, covers how security and traceability are two
important characteristics of modern systems. We need to keep the information secure
and the actions traceable. In this chapter, we will discuss how to do it using Seneca.

Preface

Chapter 6, Testing and Documenting Node.js Microservices, introduces using the main
frameworks for testing on Node.js: Mocha and Chai. We will also make use of Sinon
(another framework) to mock services. Swagger will be our choice for documenting
microservices.
Chapter 7, Monitoring Microservices, covers using PM2 to monitor our microservices.
We will use it along with Keymetrics to get the maximum benefit of such an
advanced tool.
Chapter 8, Deploying Microservices, explains how, using PM2, we are going to learn
to deploy microservices in our different environments, managing our ecosystem of
applications with a single command and reducing the overhead introduced by the
microservices architecture. We will also discuss Docker, one of the most advanced
systems to deploy applications not only in Node.js, but also in general applications.

Microservices Architecture
Microservices are becoming more and more popular. Nowadays, pretty much
every engineer on a green field project should be considering using microservices
in order to improve the quality of the systems they build. They should know the
architectural principles involving such systems. We will expose the difference
between microservices and Service-Oriented Architecture (SOA). We will also
introduce a great platform to write microservices, Node.js, which will allow us to
create high-performing microservices with very little effort.
In this chapter, you will learn about microservices from the architectural point
of view:

What are microservices?

Microservice-oriented architectures

Key benefits

SOA versus Microservices

Why Node.js?

Need for microservices

The world of software development has evolved quickly in the past 40 years. One of
the key points of this evolution has been the size of these systems. From the days of
MS-DOS, we have taken a hundred-fold leap into our present systems. This growth
in size creates a need for better ways of organizing code and software components.
Usually, when a company grows due to business needs, known as organic growth,
the software is organized on a monolithic architecture as it is the easiest and quickest
way of building software. After few years (or even months), adding new features
becomes harder due to the coupled nature of the created software.

[1]

Microservices Architecture

Monolithic software
The natural trend for new high-tech companies such as Amazon or Netflix is building
their new software using microservices, which is the ideal scenario: they get a huge
advantage of microservices-oriented software (through out this book, you will learn
how) in order to scale up their new products without a big effort. The problem is
that not all companies can plan their software upfront. Instead of planning, these
companies build software based on the organic growth experienced: few software
components group business flows by affinity. It is not rare to see companies with two
big software components: the user-facing website and the internal administration
tools. This is usually known as a monolithic software architecture.
Some of these companies face big problems when trying to scale the engineering
teams. It is hard to coordinate teams that build, deploy, and maintain a single
software component. Clashes on releases and reintroduction of bugs are a common
problem that drains a large chunk of energy from the teams. One of the solution
to this problem (it comes with benefits) is to split the monolithic software into
microservices so that the teams are able to specialize in a few smaller modules and
autonomous and isolated software components that can be versioned, updated, and
deployed without interfering with the rest of the systems of the company.
Splitting the monolith into microservices enables the engineering team to create
isolated and autonomous units of work that are highly specialized in a given task
such as sending e-mails, processing card payments, and so on.

Microservices in the real world

Microservices are small software components that are specialized in one task and
work together to achieve a higher-level task. Forget about software for a second and
think about how a company works. When someone applies for a job in a company,
he applies for a given position: software engineer, system administrator, office
manager. The reason for this can be summarized in one word: specialization. If you
are used to work as a software engineer, you will get better with the experience and
add more value to the company. The fact that you don't know how to deal with a
customer, won't affect your performance as that is not your area of expertise and will
hardly add any value to your day-to-day work.
Specialization is often the key to improve the efficiency.
Doing one thing and doing it right is one of the
mantras of software development.

[2]

Chapter 1

A microservice is an autonomous unit of work that can execute one task without
interfering with other parts of the system, similar to what a job position is to a
company. This has a number of benefits that can be used in favor of the engineering
team in order to help scale the systems of a company.
Nowadays, hundreds of systems are built using microservices-oriented architectures,
as follows:

Netflix: This is one of the most popular streaming services, it has built an
entire ecosystem of applications that collaborate in order to provide a reliable
and scalable streaming system used across the globe.

Spotify: This is one of the leading music streaming services in the world,
it has built this application using microservices. Every single widget of the
application (which is a website exposed as a desktop app using Chromium
Embedded Framework) is a different microservice that can be updated
individually.

Microservice-oriented architectures
Microservices-oriented architectures have some particularities that makes them
desirable for any mid/large-sized company that wants to keep their IT systems
resilient and in scale up/down-ready status.

How is it better?
They are not the holy grail of software engineering, but, when handled with care,
they become the perfect approach to solve most of the big problems faced by
tech-dependent companies.
It is important to keep the key principles of the microservices-oriented architecture's
design in mind, such as resilience, composability, elasticity, and so on; otherwise,
you could end up with a monolithic application split across different machines that
produces problems rather than an elegant solution.

Shortcomings
There is also some criticism around microservices-oriented architectures, as
they introduce some problems to deal with, such as latency, traceability, and
configuration management that are not present with monolithic-based software.
Some of the problems are described as follows:

Network latency: Microservices have a distributed nature so that network

latency has to be accounted for
[3]

Microservices Architecture

Operations overhead: More servers indicate more maintenance

Eventual consistency: On highly transactional systems, we need to factor

into implementation the fact that the data could be inconsistent during a
period of time (we will talk about it later in this chapter)

In general, engineers should try to evaluate the pros and cons of this approach
and make a decision on whether to use microservices or not in order to fit the
business needs.
Microservices-oriented architectures have some particularities that need to be taken
into consideration. When a software engineer is writing monolithic software, there
are some problems that are completely overlooked due to the nature of the software
being built.
For example, imagine that our software needs to send e-mails. In a monolithic
software, we would just add the functionality to the core of the application. We
might even choose to create a dedicated module to deal with e-mails (which seems
like a good idea). Now, imagine that we are creating a microservice and, instead of
adding a functionality to a big software artifact, we create a dedicated service that
can be deployed and versioned independently. In this case, we will have an extra
step that we didn't have to take into consideration, the network latency, to reach the
new microservice.
In the preceding example, no matter what approach (monolithic or microservices)
you are taking to build the software, is not a big deal; for example, if an e-mail is lost,
it is not the end of the world. As per definition, the e-mail delivery is not guaranteed,
so our application will still work, although we might receive a few complaints from
our customers.

Key design principles

There are a few key design principles that need to be taken into consideration when
building microservices. There is no golden rule and, as microservices are a recent
concept, sometimes there is even a lack of consensus on what practices to follow.
In general, we can assume the following design principles:

Microservices are business units that model the company processes.

They are smart endpoints that contain the business logic and communicate
using simple channels and protocols.

Microservices-oriented architectures are decentralized by definition. This

helps to build robust and resilient software.

[4]

Chapter 1

Business units, no components

One of the most enjoyable sides of software engineering is creating a new project.
This is where you can apply all your creativity, try new architectural concepts,
frameworks, or methodologies. Unfortunately, it is not a common situation in a
mature company. Usually, what we do is create new components inside the existing
software. One of the best design principles that you can follow when creating new
components is keeping the coupling as low as possible with the rest of the software,
so that it works as an independent unit.
Keeping a low level of coupling allows a software component
to be converted into a microservice with little to no effort.

Consider a real-world example: the application of your company now needs to be

able to process payments.
The logical decision here would be creating a new module that knows how to deal
with the chosen payment provider (credit cards, PayPal, and so on) and allows us to
keep all the payment-related business logic inside of it. Let's define the interface in
the following code:
public interface PaymentService {
PaymentResponse processPayment(PaymentRequest request) throws
MyBusinessException;
}

This simple interface can be understood by everyone, but it is the key when moving
towards microservices. We have encapsulated all the business knowledge behind
an interface so that we could theoretically switch the payment provider without
affecting the rest of the applicationthe implementation details are hidden from the
outer world.
The following is what we know until now:

We know the method name, therefore, we know how to invoke the service

The method could throw an exception of the MyBusinessException type,

forcing the calling code to deal with it

We know that the input parameter is a PaymentRequest instance

The response is a known object

[5]

Microservices Architecture

We have created a highly cohesive and loosely coupled business unit. Let's justify
this affirmation in the following:

Highly cohesive: All the code inside the payments module will do only one
thing, that is, deal with payments and all the aspects of calling a third-party
service (connection handling, response codes, and so on), such as a debit
card processor.

Loosely coupled: What happens if, for some reason, we need to switch
to a new payment processor? Is there any information bleeding out of the
interface? Would we need to change the calling code due to changes in the
contract? The answer is no. The implementation of the payment service
interface will always be a modular unit of work.

The following diagram shows how a system composed of many components gets
one of them (payment service) stripped out into a microservice:

[6]

Chapter 1

Once this module is implemented, we will be able to process the payments and
our monolithic application will have another functionality that could be a good
candidate to extract into a microservice.
Now, we can rollout new versions of the payment service, as long as the interface
does not change, as well as the contract with the rest of the world (our system
or third parties), hasn't changed. That is why it is so important to keep the
implementation independent from interfacing, even though the language does not
provide support for interfaces.
We can also scale up and deploy as many payment services as we require so that
we can satisfy the business needs without unnecessarily scaling the rest of the
application that might not be under pressure.
Downloading the example code
You can download the example code files for this book from your
account at http://www.packtpub.com. If you purchased this book
elsewhere, you can visit http://www.packtpub.com/support
and register to have the files e-mailed directly to you.
You can download the code files by following these steps:

Log in or register to our website using your e-mail address

and password.

Hover the mouse pointer on the SUPPORT tab at the top.

Click on Code Downloads & Errata.

Enter the name of the book in the Search box.

Select the book for which you're looking to download the code
files.

Choose from the drop-down menu where you purchased this

book from.

Click on Code Download.

You can also download the code files by clicking on the Code Files
button on the book's webpage at the Packt Publishing website. This
page can be accessed by entering the book's name in the Search box.
Please note that you need to be logged in to your Packt account.
Once the file is downloaded, please make sure that you unzip or
extract the folder using the latest version of:

WinRAR / 7-Zip for Windows

Zipeg / iZip / UnRarX for Mac

7-Zip / PeaZip for Linux

[7]

Microservices Architecture

Smart services, dumb communication pipes

Hyper Text Transfer Protocol (HTTP) is one of the best things to have ever
happened to the Internet. Imagine a protocol that was designed to be state-less, but
was hacked through the use of cookies in order to hold the status of the client. This
was during the age of Web 1.0, when no one was talking about REST APIs or mobile
apps. Let's see an example of an HTTP request:

As you can see, it is a human readable protocol that does not need to be explained in
order to be understood.
Nowadays, it is broadly understood that HTTP is not confined to be used in the Web,
and as it was designed, it is now used as a general purpose protocol to transfer data
from one endpoint to another. HTTP is all you need for the communication between
microservices: a protocol to transfer data and recover from transmission errors
(when possible).
In the past few years, especially within the enterprise world, there has been an effort
to create smart communication mechanisms such as BPEL. BPEL stands for Business
Process Execution Language, and instead of focusing on communication actions, it
focuses on actions around business steps.
This introduces some level of complexity in the communication protocol and makes
the business logic of the application bleed into it from the endpoints, causing some
level of coupling between the endpoints.

[8]

Chapter 1

The business logic should stay within the endpoints and not bleed into the
communication channel so that the system can be easily tested and scaled. The
lesson learned through the years is that the communication layer must be a plain
and simple protocol that ensures the transmission of the data and the endpoints
(microservices).These endpoints should embed into their implementation the fact
that a service could be down for a period of time (this is called resilience, we will talk
about this later in this chapter) or the network could cause communication issues.
HTTP usually is the most used protocol when building microservices-oriented
software but another interesting option that needs to be explored is the use of queues,
such as Rabbit MQ and Kafka, to facilitate the communication between endpoints.
The queueing technology provides a clean approach to manage the communication
in a buffered way, encapsulating the complexities of acknowledging messages on
highly transactional systems.

Decentralization
One of the major cons of monolithic applications is the centralization of everything
on a single (or few) software components and databases. This, more often than not,
leads to huge data stores that needs to be replicated and scaled according to the
needs of the company and centralized governance of the flows.
Microservices aim for decentralization. Instead of having a huge database, why not
split the data according to the business units explained earlier?
Some of the readers could use the transactionality as one of the main reasons for not
doing it. Consider the following scenario:
1. A customer buys an item in our microservices-oriented online shop.
2. When paying for the item, the system issues the following calls:
1. A call to the financial system of the company to create a transaction
with the payment.
2. A call to the warehouse system to dispatch the book.
3. A call to the mailing system to subscribe the customer to the
newsletter.

[9]

Microservices Architecture

In a monolithic software, all the calls would be wrapped in a transaction, so if, for
some reason, any of the calls fails, the data on the other calls won't be persisted
in the database.
When you learn about designing databases, one of the first and the most important
principles are summarized by the ACID acronym:

Atomicity: Each transaction will be all or nothing. If one part fails, no

changes are persisted on the database.

Consistency: Changes to the data through transactions need to guarantee its

consistency.

Isolation: The result of concurrent execution of transactions results in a

system state that would be obtained if the transactions were executed serially.

Durability: Once the transaction is committed, the data persists.

On a microservices-oriented software, the ACID principle is not guaranteed globally.

Microservices will commit the transaction locally, but there are no mechanisms that
can guarantee a 100% integrity of the global transaction. It would be possible to
dispatch the book without processing the payment, unless we factor in specific rules
to prevent it.
On a microservices-oriented architecture, the transactionality of the data is not
guaranteed, so we need to factor the failure into the implementation. A way to solve
(although, workaround is a more appropriate word) this problem is decentralizing
the governance and data storage.
When building microservices, we need to embed in the design, the fact that one
or more components could fail and degrade the functionality according to the
availability of the software.

[ 10 ]

Chapter 1

Let's take a look at the following diagram:

This diagram represents the sequence of execution on a monolithic software. A

sequential list of calls that, no matter what, are going to be executed following the
ACID principle: either all the calls (transactions) succeed or none of them do.
This is only possible as the framework and database engine designers have
developed the concept of transactions to guarantee the transactionality of the data.
When working with microservices, we need to account for what the engineers
call eventual consistency. After a partial fail on a transaction, each microservice
instance should store the information required to recover the transaction so that the
information will be eventually consistent. Following the previous example, if we send
the book without processing the payment, the payment gateway will have a failed
transaction that someone will process later on, making the data consistent again.
The best way to solve this problem is decentralizing the governance. Every endpoint
should be able to take a local decision that affects the global scope of the transaction.
We will talk more about this subject in Chapter 3, From the Monolith to Microservices.

[ 11 ]

Microservices Architecture

Technology alignment
When building a new software, there is always a concept that every developer
should keep in mind: standards.
Standards guarantee that your service will be technologically independent so that
it will be easy to build the integrations using a different programming language
or technologies.
One of the advantages of modeling a system with microservices is that we can
choose the right technology for the right job so that we can be quite efficient when
tackling problems. When building monolithic software, it is fairly hard to combine
technologies like we can do with microservices. Usually, in a monolithic software,
we are tied to the technology that we choose in the beginning.
Java Remote Method Invocation (RMI) is one example of the non-standard protocols
that should be avoided if you want your system to be open to new technologies. It is
a great way of connecting software components written in Java, but the developers
will struggle (if not fail) to invoke an RMI method using Node.js. This will tie our
architecture to a given language, which from the microservices point of view, will kill
one of the most interesting advantages: technology heterogeneity.

How small is too small?

Once we have decided to model our system as a set of microservices, there is always
one question that needs an answer: how small is too small?
The answer is always tricky and probably disappointing: it depends.
The right size of the microservices in a given system depends on the structure of
the company as well as the ability to create software components that are easily
manageable by a small team of developers. It also depends on the technical needs.
Imagine a system that receives and processes banking files; as you are probably
aware, all the payments between banks are sent in files with a specific known
format (such as Single Euro Payments Area (SEPA) for Euro payments). One of the
particularities of this type of systems is the large number of different files that the
system needs to know how to process.
The first approach for this problem is tackling it from the microservices point of
view, separating it from any other service creating a unit of work, and creating one
microservice for each type of file. It will enable us to be able to rollout modifications
for the existing file processors without interfering with the rest of the system.
It will also enable us to keep processing files even though one of the services is
experiencing problems.
[ 12 ]

Chapter 1

The microservices should be as small as needed, but keep in mind that every
microservice adds an overhead to the operations team that needs to manage a new
service. Try to answer the question how small is too small? in terms of manageability,
scalability, and specialization. The microservice should be small enough to be
managed and scaled up (or down) quickly without affecting the rest of the system,
by a single person; and it should do only one thing.
As a general rule, a microservice should be small
enough to be completely rewritten in a sprint.

Key benefits
In the previous topic, we talked about what a microservices-oriented architecture is.
I also exposed the design principles that I have learned from experience, as well as
showed a few benefits of this type of architecture.
Now, it is time to outline these key benefits and show how they will help us to
improve the quality of our software, as well as be able to quickly accommodate the
new business requirements.

Resilience
Resilience is defined in Wikipedia as the ability of a system to cope with change. I like
to think about resilience as the ability of a system to gracefully recover from an exception
(transitory hardware failure, unexpectedly high network latency, and so on) or a
stress period without affecting the performance of the system once the situation has
been resolved.
Although it sounds simple, when building microservices-oriented software, the
source of problems broadens due to the distributed nature of the system, sometimes
making it hard (or even impossible) to prevent all abnormal situations.
Resilience is the ability to gracefully recover from errors. It also adds another level of
complexity: if one microservice is experiencing problems, can we prevent a general
failure? Ideally, we should build our system in a way that the service response is
degraded instead of resulting in a general failure, although this is not always easy.

[ 13 ]

Microservices Architecture

Scalability
Nowadays, one of the common problems in companies is the scalability of the
systems. If you have worked on a monolithic software before, I am sure that you have
experienced capacity problems at some point, alongside the growth of the company.
Usually, these problems are not across all the layers or subsystems of the application.
There is always a subsystem or service that performs significantly slower than the
rest, causing the entire application to fail if it is not able to cope with the demand.
The following diagram describes how a microservice can be scaled up (two mailing
services) without interfering with the rest of the system:

[ 14 ]

Chapter 1

An example of these weak points in the world of car insurance is the

service that calculates the quote for a given list of risk factors. Would it
make sense to scale the full application just to satisfy the demand for this
particular part? If the answer that you have in mind is no, you are one
step closer to embracing microservices. Microservices enable you to scale
parts of the system as the demand ramps up for a particular area of it.

If our insurance system was a microservice-oriented software, the only thing needed
to resolve the high demand for quote calculations would've been to spawn more
instances of the microservice (or microservices) responsible for their calculation. Please
bear in mind that scaling up services could add an overhead for operating them.

Technology heterogeneity
The world of software is changing every few months. New languages are coming
to the industry as a de facto standard for a certain type of systems. A few years
ago, Ruby on Rails appeared at the scene and rose as one of the most used web
frameworks for new projects in 2013. Golang (a language created by Google) is
becoming a trend nowadays as it combines huge performance with an elegant
and simple syntax that can be learned by anyone with some experience in another
programming language in a matter of days.
In the past, I have used Python and Java as successful alternatives to write
microservices.
Java especially, since Spring Boot was released, is an attractive technology stack to
write agile (to write and operate) microservices.
Django, is also a powerful framework on Python to write microservices. Being very
similar to Ruby on Rails, it automates database migrations and makes the creation of
CRUD (Create Read Update Delete) services an incredibly easy task.
Node.js took the advantage of a well-known language, JavaScript, to create a new
server-side stack that is changing the way engineers create new software.
So, what is wrong in combining all of them? In all fairness, it is an advantage: we can
choose the right tool for the right job.
Microservices-oriented architectures enable you to do it, as long as the integration
technologies are standard. As you learned before, a microservice is a small and
independent piece of software that can operate by itself.

[ 15 ]

Microservices Architecture

The following diagram shows how the microservices hide data storage/gathering,
having only the communication points in commonmaking them a good example
of low coupling (one service implementation change won't interfere with any other
service):

We have talked about performance earlier. There are always parts of our systems
that are under more pressure than others. With modern multicore CPUs, parallel
(concurrent) programming could solve some of these performance issues, however,
Node.js is not a good language to parallelize tasks. We could choose to rewrite the
microservice under pressure using a more appropriate language, such as Erlang, to
manage concurrency in a more elegant way. It should take no more than two weeks
to do it.

[ 16 ]

Chapter 1

There is a downside to using multiple technologies on the same system: the

developers and system administrators need to know all (or a few) of them.
Companies that embraced microservices usually try to stick with one core technology
(in this book, we will be using Node.js) and some auxiliary technologies (although
we will be using Docker to manage the deployments, we could use Capistrano or
Fabricator to manage the releases).

Replaceability
Replaceability is the ability to change one component of a system without interfering
with how the system behaves.
When talking about software, replaceability comes along with low coupling. We
should be writing our microservices in a way that the internal logic will not be
exposed to the calling services so that the clients of a given service do not need
to know about how it is implemented, just the interface. Let's take a look at the
following example. It is written in Java as we only need to see the interface to
identify the pitfalls:
public interface GeoIpService {
/**
* Checks if an IP is in the country given by an ISO code.
**/
boolean isIn(String ip, String isoCode) throws
SOAPFaultException;
}

This interface, at first look, is self explanatory. It checks whether a given IP is in a

given country and throws a SOAPFaultException, which is a big problem.
If we build the client that consumes this service, factoring into their logic,
capture, and processing of the SoapFaultException, we are exposing internal
implementation details to the outer world and making it hard to replace the
GeoIpService interface. Also, the fact that we are creating a service related to a part
of our application logic is an indication of the creation of a bounded context: a highly
cohesive service or set of services that work together to achieve one purpose.

[ 17 ]

Microservices Architecture

Independence
No matter how hard we try, the human brain is not designed to solve complex
problems. The most efficient mode of functioning for the human brain is
one thing at the time so that we break down complex problems into smaller ones.
Microservices-oriented architectures should follow this approach: all the services
should be independent and interact through the interface up to a point that they can
be developed by different groups of engineers without any interaction, aside from
agreeing the interfaces. This will enable a company adopting microservices to scale
up, or down, the engineering teams, depending on the business needs, making the
business agile in responding to peaks of demand or periods of quietness.

Why is replaceability important?

In a previous section, we talked about the right size of a microservice. As a general
rule of thumb, a team should be able to rewrite and deploy a microservice in a sprint.
The reason behind it is the technical debt.
I would define technical debt as the deviation from the original technical design
to deliver the expected functionality within a planned deadline. Some of these
sacrifices or wrong assumptions often lead to poorly written software that needs to
be completely refactored or rewritten.
In the preceding example, the interface is exposing to the outer world the fact that
we are using SOAP to call a web service, but we will need to change the code on the
client side as a REST client has certainly nothing to do with SOAP exceptions.

Easy to deploy
Microservices should be easy to deploy.
Being software developers, we are well aware that a lot of things could go wrong,
preventing a software from being deployed.
Microservices, as stated before, should be easy to deploy for a number of reasons, as
stated in the following list:

Small amount of business logic (remember the two weeks re-write from scratch
rule of thumb) leading into simpler deployments.

Microservices are autonomous units of work, so upgrading a service is a

contained problem on a complex system. No need to re-deploy the entire
system.

[ 18 ]

Chapter 1

Infrastructure and configuration on microservices architectures should be

automated as much as possible. Later in the book, we will learn how to use
Docker to deploy microservices and what are the benefits over the traditional
deployment techniques are.

SOA versus microservices

Service-Oriented Architectures (SOA) has been around for a number of years. SOA
is a great principle to design software. They are self-contained components providing
services to other components. As we agreed before, it is all about maintaining low
coupling on the different modules of the system as if it was a puzzle so that we can
replace the pieces without causing a big impact on the overall system.
In principle, SOA looks very similar to microservices architectures. So what is
the difference?
Microservices are fine-grained SOA components. In other words, a single SOA
component can be decomposed in a number of microservices that can work together
in order to provide the same level of functionality:

[ 19 ]

Microservices Architecture

Microservices are fine-grained SOA components.

They are lightweight services with a narrow focus.

Another difference between microservices and SOA is the technologies used for
interconnecting and writing the services.
J2EE is a technology stack that was designed to write SOA architectures as it
enforced enterprise standards. Java Naming and Directory Interface, Enterprise
Java Beans, and Enterprise Service Bus (ESB) were the ecosystems where SOA
applications were built and maintained. Although ESB is a standard, very few
engineers who graduated after 2005 have heard about ESB, even fewer have used it,
and nowadays the modern frameworks such as Ruby on Rails do not even consider
such complex pieces of software.
On the other hand, microservices enforce the use of standards (such as HTTP) that
are broadly known and broadly interoperable. We can choose the right language or
tool to build a component (microservice) following one of the key benefits explained
earlier in this chapter, in the Technology heterogeneity section.
Aside from the technology stack and the size of the services, there is an even bigger
difference between SOA and microservices: the domain model. Earlier in this
chapter, we have talked about decentralization. Decentralization of the governance,
but, moreover, decentralization of the data. In a microservices-based software, every
microservice should store its own data locally, isolating the domain models to a
single service; whereas, on an SOA oriented-software, the data is usually stored in a
few big databases and the services share the domain models.

Why Node.js?
A few years ago, I didn't believe in Node.js. To me, it was a trend more than a
real tool to solve problems JavaScript in the server? That didn't look right. In all
fairness, I didn't even like JavaScript. Then, the modern frameworks such as jQuery
or Angular.js came to the rescue. They solved one of the problems, which was the
cross-browser compatibility. Where before we needed to factor in at least three
different browsers, after jQuery all this logic was nicely encapsulated in a library
so that we didn't need to worry about compatibility as long as we followed the
jQuery documentation.
Then, JavaScript became more popular. Suddenly, all the internal tools were written
with Single-Page Application (SPA) frameworks with a heavy usage of JavaScript,
therefore, the majority of developers nowadays, one way or another, are proficient
in JavaScript.
[ 20 ]

Chapter 1

Then, someone decided to take JavaScript out of the browser, which was a great
idea. Rhino, Node.js, and Nashorn are examples of runtimes that can execute
standalone JavaScript. Some of them can even interact with the Java code, enabling
the developer to import Java classes into a JavaScript program, which gives you the
access to an endless set of frameworks already written in Java.
Let's focus on Node.js. Node.js is the perfect candidate for microservices-oriented
architectures for a number of reasons, as stated in the following list:

Easy to learn (although it can be hard to master)

Easy to scale

Highly testable

Easy to deploy

Dependency management through npm

There are hundreds of libraries to integrate with the majority of standard

protocols

These reasons, along with others that we will develop in the following chapters,
make Node.js the perfect candidate for building solid microservices.

API aggregation
Seneca is the framework that I have chosen for development in the following
chapters. One of the most attractive characteristics of Seneca is API aggregation.
API aggregation is an advanced technique to compose an interface by aggregating
different functionalities (plugins, methods, and so on) to it.
Let's take a look at the following example:
var express = require('express');
var app = express();
app.get('/sayhello', function (req, res) {
res.send('Hello World!');
});
app.get('/saygoodbye', function(req, res) {
res.send('Bye bye!');
});
var server = app.listen(3000, function () {
var host = server.address().address;
var port = server.address().port;
console.log('App listening at http://%s:%s', host, port);
});
[ 21 ]

Microservices Architecture

The preceding example uses Express, a very popular web framework for Node.js.
This framework is also built around the API aggregation technique. Let's take a look
at the fourth and seventh lines. In these lines, the developer registers two methods
that are to be executed when someone hits the URLs /sayhello and /saygoodbye
with a GET request. In other words, the application is composed of different smaller
and independent implementations that are exposed to the outer world on a single
interface, in this case, an app listening on the 3000 port.
In the following chapters, I will explain why this property is important and how to
take advantage of it when building (and scaling) microservices.

The future of Node.js

JavaScript was first designed to be a language executed in the web browser. For
those who worked or studied, using C/C++ was very familiar and that was the key
for its adoption as a standard for the dynamic manipulation of documents in Web
2.0. Asynchronous JavaScript and XML (AJAX) was the detonator for JavaScript
growth. Different browsers had different implementations of the request objects so
that the developers had a hard time to write a cross-browser code.
The lack of standards led to the creation of many frameworks that encapsulated the
logic behind AJAX, making easy-to-write cross-browser scripts.
JavaScript is a script language. It was not designed to be object oriented, neither was
it designed to be the language of choice for large applications as the code tends to
get chaotic and it is hard to enforce standards across different companies on how
the code should be laid out. Every single company where I worked has different best
practices and some of them are even contradictory.
European Computer Manufacturers Association (ECMA) came to the rescue.
ECMAScript 6, the next standard for ECMA languages (JavaScript, ActionScript,
Rhino, and so on) introduces the concept of classes, inheritance, collections, and a
number of interesting features that will make the development of JavaScript software
easier and more standard than the actual V8 specification.
One of these features that I consider more interesting is the introduction of the class
keyword that allows us to model our JavaScript software with objects.
At the moment, the majority of browsers support a large number of these features, but
when it comes to Node.js, only a few of them are implemented by default and some of
them are implemented by passing special flags to the interpreter (harmony flags).
In this book, I will try to avoid the ECMAScript 6 features, sticking to the V8
specification as it is widely known by the majority of developers and, once someone
knows JavaScript V8, it is fairly easy to ramp up on ECMAScript 6.
[ 22 ]

Chapter 1

Summary
In this chapter, we studied the key concepts around microservices, as well as the best
practices to be followed when designing high-quality software components towards
building robust and resilient software architectures that enable us to respond quickly
to the business needs.
You have also learned the key benefits such as the possibility of using the right
language for the right service (technology heterogeneity) on the microservices-oriented
architectures as well as some of the pitfalls that could make our life harder, such as
the overhead on the operational side caused by the distributed nature of the
microservices-oriented architectures.
Finally, we discussed why Node.js is a great tool for building microservices, as well
as how we could benefit from JavaScript to build high-quality software components
through techniques like API aggregation.
In the following chapters, we will be developing the concepts discussed in this
chapter, with code examples and further explanation about the topics I have
learned over the years.
As explained before, we will focus on the V8 version of JavaScript, but I will
provide some hints on how to easily write upgradeable components to embrace
ECMAScript 6.

[ 23 ]

Get more information Developing Microservices with Node.js

Where to buy this book

You can buy Developing Microservices with Node.js from the Packt Publishing website.
Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet
book retailers.
Click here for ordering and shipping details.

www.PacktPub.com

Stay Connected: