The best way to understand how important microservices are in real life is knowing some platforms that decided to evolve and use microservices thinking about the future and making the maintenance and scalability easier, faster, and more effective:

Next, we will look at the disadvantages of the microservices architecture. When asking developers about this, they agree that the major problem with microservices is the debugging on the production server.

Debugging an application based on microservices can be a little tedious when you have hundreds of microservices in your application and you have to find where a problem is; you need to spend time looking for the microservice that is giving you the error. Each microservice works like an individual machine, so to look at a specific log you have to go to the specific microservice. Fortunately, there are some tools to help us out with this subject by getting the logs from all the different microservices in your application and putting them together into a single location. In the subsequent chapters, we will look at these kinds of tools.

Another disadvantage is that it is necessary to maintain every single microservice as an entire server; in other words, every single microservice can have one or more databases, logs, different services, or library versions, and even the code can be in a different language, so if it is difficult to maintain a single server and doing it with hundreds will waste money and time.

Also, the communication between microservices is very important---they have to work like clocks, so communication is essential for the application. To do this, the communication between the development teams will be necessary to tell each other what they need and also to write good documentation for each microservice.

A good practice to work with microservices is having everything automatized or at least everything possible. Maybe the most important part is the deployment. If it is necessary to deploy hundreds of microservices, it can be difficult. So, the best way is to automatize these kinds of tasks. We will look at how to do this in the subsequent chapters.

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.

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.

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.

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.

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.

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.

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.

In 1994, Rasmus Lerdorf created what we can say was the first version of PHP. He built a small suite of Common Gateway Interfaces (CGIs) in the C programming language to maintain his personal web page. This suite of scripts was called Personal Home Page Tools, but it was more commonly referenced as PHP Tools.

Time passed and Rasmus rewrote and extended the suite so that it could work with web forms and have the ability to communicate with databases. This new implementation was called Personal Home Page/Forms Interpreter or PHP/FI and served as a framework upon which other developers could build dynamic web applications. In June 1995, the source code was opened to the public under the name of Personal Home Page Tools (PHP Tools) version 1.0, allowing developers from all over the world to use it, fix bugs and improve the suite.

The first idea around PHP/FI was not to create a new programming language, and Lerdorf let it grow organically, leading to some problems like the inconsistency of function names or their parameters. Sometimes the function names were the same as the low-level libraries that PHP was using.

In October 1995, Rasmus released a new rewrite of the code; this was the first release that was considered as an advanced scripting interface and PHP started to become the programming language that it is today.

As a language, PHP was designed to be very similar to C in structure so that it would be easier to be adopted by developers who were familiar with C, Perl, or similar languages. Along with the growth of the features of the language, the number of early adopters also began to grow. A Netcraft survey of May, 1998 indicated that nearly 60,000 domains had headers containing PHP (around 1% of the domains on the Internet at the time), which indicated that the hosting server had it installed.

One important point in PHP history was when Andi Gutmans and Zeev Suraski of Tel Aviv, Israel, joined the project in 1997. At this time, they did another complete rewrite of the parser and started the development of a new and independent programming language. This new language was named PHP, with the meaning becoming a recursive acronym---PHP (Hypertext Preprocessor).

The official release of PHP 3 was in June 1998, including a great number of features that made the language suitable for all kinds of projects. Some of the features included were a mature interface for multiple databases, support for multiple protocols and APIs, and the ease of extending the language itself. Among all the features, the most important ones were the inclusion of object-oriented programming and a more powerful and consistent language syntax.

Andi Gutmans and Zeev Suraski founded Zend Technologies and started the rewrite of PHP's core, creating the Zend Engine in 1999. Zend Technologies became the most important PHP company and the main contributor to the source code.

This was only the beginning and as years passed, PHP grew in features, language stability, maturity, and developer adoption.

Now that we have some historical background, we can focus on the main milestones achieved by PHP throughout the years. Each release increased the language stability and added more and more features.

PHP is one of the most used programming languages you can use to build your web projects. In case you are not yet sure if PHP is the appropriate language for your next application, let us now to tell you the main advantages of using PHP:

Like any programming language, PHP also has some disadvantages. Some of the most common mentioned disadvantages flagged are: security issues, unsuitable for large applications, and weak types. PHP started as a collection of CGIs and has become more modern and robust throughout the years, so it is pretty robust and flexible for a young programming language (in comparison with other languages).

In any case, an experienced developer will have no problem overcoming these disadvantages when building their application if they use the best practices.

As you can already see, the evolution of PHP was enormous. It has one of the most vibrant communities, was made for the web, and has all the power you need to create any kind of project. Without a doubt, PHP will be the right language for you to express your best ideas.