Book Image

PHP Microservices

By : Pablo Solar Vilariño, Carlos Pérez Sánchez
Book Image

PHP Microservices

By: Pablo Solar Vilariño, Carlos Pérez Sánchez

Overview of this book

The world is moving away from bulky, unreliable, and high-maintenance PHP applications, to small, easy-to-maintain and highly available microservices and the pressing need is for PHP developers to understand the criticalities in building effective microservices that scale at large. This book will be a reliable resource, and one that will help you to develop your skills and teach you techniques for building reliable microservices in PHP. The book begins with an introduction to the world of microservices, and quickly shows you how to set up a development environment and build a basic platform using Docker and Vagrant. You will then get into the different design aspects to be considered while building microservices in your favorite framework and you will explore topics such as testing, securing, and deploying microservices. You will also understand how to migrate a monolithic application to the microservice architecture while keeping scalability and best practices in mind. Furthermore you will get into a few important DevOps techniques that will help you progress on to more complex domains such as native cloud development, as well as some interesting design patterns. By the end of this book you will be able to develop applications based on microservices in an organized and efficient way. You will also gain the knowledge to transform any monolithic applications into microservices.
Table of Contents (19 chapters)
PHP Microservices
Credits
About the Authors
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

How to focus your development on microservices


Developing microservices is a new way of thinking. Therefore, it can be difficult when you encounter how the application will be designed and built for the first time. However, if you always remember that the most important idea behind microservices is the need to decompose your application into smaller logical pieces, you are already halfway there.

Once you understand this, the following core ideas will help you with the design and build process of your application.

Always create small logical black boxes

As a developer, you always start with the big picture of what you will build. Try to decompose the big picture into small logical blocks that only do one thing. Once the multiple small pieces are ready, you can start building complex systems, ensuring that the foundations of your application are solid.

Each of your microservices is like a black box with a public interface, which is the only way to interact with your software. The main recommendation you need to have always in mind is to build a very stable API. You can change the implementation of an API call without many problems, but if you change the way of calling or even the response of this call, you will be in big trouble. In the case of deep changes to your API, ensure that you use some kind of versioning so that you can support the old and new versions.

Network latency is your hidden enemy

The communication between services is made through API calls using the network as a connection pipe. This message exchange takes some time and it will not always be the same due to multiple factors. Imagine that you have service_a on one machine and a service_b on a different machine. Do you think that the network latency will always be the same? What happens if, for example, one of the servers is under a high load and takes some time to process requests? To reduce time, always keep an eye on your infrastructure, monitor everything, and use compression if it is available.

Always think about scalability

One of the main advantages of a microservice application is that each service can be scaled up or down. This flexibility can be achieved by reducing the number of stateful services to the minimum. A stateful service relies on data persistence, making it difficult to move or share the data without having data consistency problems.

Using autodiscovery and autoregistry techniques, you can build a system that knows which one will deal with each request at all times.

Use a lightweight communication protocol

Nobody likes to wait, not even your microservices. Don't try to reinvent the wheel or use an obscure but cool communication protocol, use HTTP and REST. They are known by all web developers, they are fast, reliable, easy to implement, and very easy to debug. If you need to increase the security, implement SSL/TSL.

Use queues to reduce a service load or make async executions

As a developer, you want to make your system as fast as possible. Therefore, it makes no sense to increase the execution time of an API call just because it is waiting for some action that can be done in the background. In these cases, the best approach is the use of queues and job runners in charge of this background processing.

Imagine that you have a notification system that sends an e-mail to a customer when placing an order on your microservice e-commerce. Do you think that the customer wants to wait to see the payment successful page only because the system is trying to send an e-mail? In this case, a better approach is to enqueue the message so that the customer will have a pretty instant thank you page. Later, a job runner will pick up the queued notification and the e-mail will be sent to the customer.

Be ready for the worst case scenario

You have a nice, new, good-looking site built on top of microservices. Are you ready for the moment when everything goes wrong? If you are suffering a network partition, do you know if your application will recover from that situation? Now, imagine that you have a recommendation system and it is down, are you going to give the customers a default recommendation while you try to recover the dead service? Welcome to the world of distributed systems where when something goes wrong, it can get worse. Always keep this in mind and try to be ready for any scenario.

Each service is different, so keep different repositories and build environments

We are decomposing an application into small parts which we want to scale and deploy independently, so it makes sense to keep the source in different repositories. Having different build environments and repositories means that each microservice has its own lifecycle and can be deployed without affecting the rest of your application.

In the subsequent chapters, we will take a deeper look at all these ideas and how to implement them using different driven developments.