34,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
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.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 460
Veröffentlichungsjahr: 2017
Ähnliche
PHP Microservices
PHP Microservices
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: March 2017
Production reference: 1240317
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B32PB, UK.
ISBN 978-1-78712-537-7
www.packtpub.com
Credits
Authors
Carlos Pérez Sánchez
Pablo Solar Vilariño
Copy Editor
Shaila Kusanale
Reviewers
Gabor Zelei
Project Coordinator
Vaidehi Sawant
Commissioning Editor
Aaron Lazar
Proofreader
Safis Editing
Acquisition Editor
Divya Poojari
Indexer
Mariammal Chettiyar
Content Development Editor
Anurag Ghogre
Graphics
Jason Monteiro
Technical Editor
Jijo Maliyekal
Subhalaxmi Nadar
Production Coordinator
Melwyn Dsa
About the Authors
Carlos Pérez Sánchez is a backend web developer with more than 10 years of experience in working with the PHP language. He loves finding the best solution for every single problem on web applications and coding, looking to push forward the best practices for development, ensuring a high level of attention to detail.
He has a bachelors degree in computer engineering from the University of Alicante in Spain, and he has worked for different companies in the United Kingdom and Spain. He has also worked for American companies and is currently working for Pingvalue. You can connect with him on LinkedIn at https://www.linkedin.com/in/mrcarlosdev.
To my girlfriend, Becca, family, and friends—thanks for your unconditional support in every single stage of my life.
Pablo Solar Vilariño is a software developer who became interested in web development when PHP 4 started becoming a popular language.
Over the last few years, he has worked extensively with web, cloud, and mobile technologies for medium-to-large companies and is currently an e-commerce developer at NITSNETS.
He has a passion for new technologies, code standards, scalability, performance, and open source projects.
Pablo can be approached online at https://pablosolar.es/.
To everyone who has ever believed in me.
About the Reviewer
Gabor Zelei is a polyglot software engineer with a versatile background in both software engineering and operations. He’s had a decade-long love for PHP and LAMP/LEMP stacks in general; he enjoys working with upcoming technologies and methodologies and is a big fan of clean, well-structured and standards-compliant code.
During his career, he has worked for small startups as well as large enterprise companies. Currently, he lives in Dublin, Ireland, where he works as a senior software developer for a leading online marketplace company.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com.
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1787125378.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Preface
Microservices are the new kids on the block. They are a way of solving problems, but it does not mean that they will always be the best solution. Microservices are a full and complex architecture that you need to understand deeply in order to be able to apply them successfully in the real world.
We know that understanding and having everything in place for microservices can take time and can be very complex, so for this reason we wrote this book--to give you a small guide to microservices, from A to Z. This book will only be a glimpse of what you can do with microservices, but we hope that it will be at least a helpful start into this world.
We will start our journey in this book by explaining the foundations of this architecture, the basic knowledge you will need to have. As you advance through the book, we will be increasing the level of difficulty. However, we will guide you through every step of the process, so at the end of the book you will be able to know whether a microservice architecture is the best solution for your problem and how can you apply this architecture.
Enjoy your microservices!
What this book covers
Chapter 1, What are Microservices?, will teach you all the basics of microservices.
Chapter 2, Development Environment, will take you through setting up your development machine to build microservices successfully.
Chapter 3, Application Design, will help you start designing your application, creating the foundation of your project.
Chapter 4, Testing and Quality Control, looks at how important testing your application is and how can you add tests to your application.
Chapter 5, Microservices Development, will cover building a microservices application, explaining each step involved.
Chapter 6, Monitoring, covers how to monitor your application so that you can always know how your application is behaving.
Chapter 7, Security, focuses on how you can add an extra layer of complexity to your application to make it more secure.
Chapter 8, Deployment, explains how you can deploy your application successfully.
Chapter 9, From Monolithic to Microservices, discusses an example of how a monolithic application can be transformed into a microservice.
Chapter 10, Strategies for Scalability, outlines how you can create a scalable application.
Chapter 11, Best Practices and Conventions, will refresh your knowledge about the best practices and conventions you should use in an application.
Chapter 12, Cloud and DevOps, looks at the different cloud providers and the DevOps world.
What you need for this book
To follow along with this book, you’ll need a computer with an Internet connection to download the required software and Docker images. At some point, you will need at least a text editor or an IDE, and we highly recommend PHPStorm for this job.
Who this book is for
This book is for experienced PHP developers who want to go a step ahead in their careers and start building successful scalable and maintainable applications, all based on microservices. After reading the book, they will be able to know whether microservices are the best solutions to their problems and if it is the case, create a successful application.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "The next lines of code read the link and assign it to the to the BeautifulSoup function."
A block of code is set as follows:
version: '2' services:When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
version: '2' services:Any command-line input or output is written as follows:
$ uname -r 3.10.0-229.el7.x86_64New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Click on the toolbar whale for Preferences... and other options."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
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:
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/PHP-Microservices. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at [email protected] with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Chapter 1. What are Microservices?
Good projects need good solutions; this is why developers are always looking for better ways to do their jobs. There is no best solution for all projects because every single project has different needs and the architect (or the developer) has to find the best solution for that specific project.
Microservices are maybe a good approach to solve problems; in the last few years, companies such as Netflix, PayPal, eBay, Amazon, and Spotify have chosen to use microservices in their own development teams because they believed them to be the best solution for their projects. To understand why they chose microservices and understand the kinds of projects you should use them in, it is necessary to know what a microservice is.
Firstly, it is essential to understand what a monolithic application is, but basically, we can define a microservice as an extended Service Oriented Architecture. In other words, it is a way to develop an application by following the required steps to turn it into various little services. Each service will execute itself and communicate with others through requests, usually using APIs on HTTP.
To further understand what microservices are, we first need to understand what a monolithic application is. It is the typical application that we have been developing for the last few years, for example in PHP, using a framework like Symfony; in other words, all the applications we have been developing are divided into different parts, such as frontend, backend, and database, and also use the Model-View-Controller (MVC) pattern. It is important to differentiate between MVC and microservices. MVC is a design pattern and microservices are a way to develop an application; therefore, applications developed using MVC could still be monolithic applications. People may think that if we split our application into different machines and divide the business logic from the model and the view, the application is then based on microservices, but this is not correct.
However, using a monolithic architecture still has its advantages. There are also various huge web applications, such as Facebook, that use it; we just need to know when we need to use a monolithic architecture and when we need to use microservices.
Monolithic versus microservices
Now, we will discuss the advantages and disadvantages of using monolithic applications and how microservices improve a specific project by giving a basic example.
Imagine a taxi platform like Uber; the platform in this example will be a small one with only the basic things in order to understand the definitions. There are customers, drivers, cities, and a system to track the location of the taxi in real time:
In a monolithic system, we have all this together---we have a common database with the customers and drivers linked to cities and all these are linked to the system to track taxis using foreign keys.
All this can also be hosted on different machines using master-slave databases; the backend can be in different instances using a load balancer or a reverse proxy and the frontend can use a different technology using Node.js or even plain HTML. Even so, the platform will be a monolithic application.
Lets see an example of possible problems faced in a monolithic application:
A microservice is a simple, isolated entity with a concrete proposal. It is independent and works with the rest of the microservices by communicating through an agreed channel as you can see in the next picture:
For developers who are used to working on object-oriented programming, the idea of a microservice would be something like an encapsulated object working on a different machine and isolated from the other ones working on different machines too.
Following the same example as before, if we have a problem on the system to track taxis, it would be necessary to isolate all the code related to this part of the application. This is a little complex and will be explained in detail in Chapter 9, From Monolithic to Microservices, but in general terms, it is a database used exclusively by the system to track taxis, so we need to extract the part for this purpose and the code needs to be modified to work with the extracted database. Once the goal is achieved, we will have a microservice with an API (or any other channel) that can be called by the rest of the monolithic application.
This will avoid the problems mentioned before---Joe and John can work on their own issue because once the application is divided into microservices, they will work on the customer or driver microservice. If Joe has to change code or include a new field, he will only need to change it in his own entity and John will consume the drivers API to communicate with it from the customer's part.
The scalability can be done just for this microservice, so it is not necessary to scale the entire application by spending money and resources and if the system to track taxis is down, the rest of the application will work without any problems.
Another advantage of using microservices is that they are agnostic to the language; in other words, it is possible to use different languages for each microservice. A microservice written in PHP can talk to others written in Python or Ruby because they only give the API to the rest of the microservices, so they just have to share the same interface to communicate with each other.
Service Oriented Architectures versus microservices
When a developer encounters microservices and they know the Service Oriented Architecture (SOA) style of software design, the first question they ask themselves is whether SOA and microservices are the same thing or whether they are related, and the answer is a little bit controversial; depending on who you ask, the answer will be different.
According to Martin Fowler, SOA focuses on integrating monolithic applications between themselves, and it uses an Enterprise Service Bus (ESB) to achieve this.
When the SOA architectures began to appear, these ones tried to connect different components between themselves, and this is one of the characteristics of microservices, but the problem with SOA was that it needed many things surrounding the architecture to work properly, such as ESB, Business process management (BPM), service repositories, register, and more things, so it made it more difficult to develop. Also, in order to change some parts of a code, it was necessary to agree with the other development teams before doing it.
All these things made the maintenance and code evolution difficult, and the time to market long; in other words, this architecture was not the best for applications that often needed to make changes live.
There are other opinions regarding SOA. Some say that SOA and microservices are the same, but SOA is the theory and microservices is a good implementation. The need to use an ESB or communicate using WSDL or WADL was not a must, but it was defined as the SOA standard. As you can see on the next picture, your architecture using SOA and ESB will look like this:
The requests arrive via different ways; this is the same way microservices work, but all the requests reach the ESB and it knows where it should call to get the data.
Microservices characteristics
Next, we will look at the key elements of a microservice architecture:
Successful cases
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:
Disadvantages of microservices
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.
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.
Advantages of using PHP on microservices
To understand why PHP is a suitable programming language for building microservices, we need to take a small peek into its history, where it comes from, which problems it was trying to solve, and the evolution of the language.
A short history of PHP
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.
PHP milestones
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.
Version 4.x
PHP 4 was the first release, which included the Zend Engine. This engine increased the average performance of PHP. Along with the Zend Engine, PHP 4 included support for more web servers, HTTP sessions, output buffering, and increased security.
Version 5.x
PHP 5 was released on July 13, 2004 using the Zend Engine II, which increased the language performance once again. This release included important improvements for object-oriented (OO) programming, making the language more flexible and robust. Now, users were able to choose between developing applications in a procedural or a stable OO way; they could have the best of both worlds. In this release, one of the most important extensions used to connect to data stores was also included---the PHP Data Objects (PDO) extension.
With PHP 5 becoming the most stable version in 2008, many open source projects started ending their support for PHP 4 in their new code.
Version 6.x
This release was one of the most famous failures for PHP. The development of this major release started in 2005 but, in 2010, it was abandoned due to difficulties with the Unicode implementation. Not all the work was thrown away and most of the features, one of them being namespaces, were added to the previous releases. As a side note, version 6 is generally associated with a failure in the tech world: PHP 6, Perl 6, and even MySQL 6 were never released.
Version 7.x
This was a long awaited release---one release to rule them all and a release with performance levels seen never before.
On December 3, 2015, version 7.0.0 was released with the last Zend Engine available. The performance increase obtained only by changing the running version on your machine reached up to 70%, with a very small memory footprint.
The language also evolved, and PHP now had a better 64-bit support and a secure random number generator. Now you could create anonymous classes or define return types among other major changes.
This release became serious competition to the other so-called enterprise languages.
Advantages
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:
There are a number of ways of deploying your code into production. For instance, you can track your code in a Git repository and do a Git pull on your server later. You could also push your files through FTP to the public location.You can even build a Continuous Integration/Continuous Delivery (CI/CD) system with Jenkins, Docker, Terraform, Packer, Ansible, or other tools. The complexity of the deploy will always match the project complexity.
Easy to install: PHP has prebuilt packages for the major operating systems: it can be installed on Linux, Mac, Windows, or Unix. Sometimes the packages are available inside the package system (for instance, apt). In other cases, you need external tools to install it, such as Homebrew. In the worst case scenario, you can download the source code and compile it on your machine.Open Source: All the PHP source code is available at GitHub, so it is really simple for any developer to take a deep look at how everything works. This openness allows a programmer to participate in the project, extending the language or fixing the bugs. The license used in PHP is a Berkeley Software Distribution (BSD) style license without the copyleft restrictions associated with GPL.High running speed (PHP 7): In the past, PHP was not fast enough, but this situation changed completely with PHP 7. This major release is based on the PHP Next-Gen (PHPNG) project with Zend Technologies as the leader. The idea behind PHPNG was to speed up PHP applications and they did this very well. The performance gains can vary between 25% and 70% only by changing the PHP version.High number of frameworks and libraries available: The PHP ecosystem is very rich in libraries and frameworks. The common way to find a suitable library for your project is using PEAR and PECL.Regarding the available frameworks, you can use one of the best, for example Zend Framework, Symfony, Laravel, Phalcon, CodeIgniter, or you can build one from scratch if you can't find one that meets your requirements. The best part about this is that all of these are open source, so you can always extend them.
High development speed: PHP has a relatively small learning curve, which can help you start coding from the beginning. Also, the similarities in syntax with C, Perl, and other languages can make you understand how everything works in no time. PHP avoids wasting time waiting for the compiler to generate our build.Easy to debug: As you probably know, PHP is an interpreted language. Therefore, when trying to solve an issue, you have multiple options to succeed. The easy way is dropping a few var_dump or print_r calls to view what the code is doing. For a deeper view of the execution, you can link your IDE to Xdebug or Zend Debug and start tracing your application.Easy to test: No modern programming language will survive in the wild without an appropriate test suite, so you have to ensure that your application will continue running as expected. Don't worry, the PHP community has your back as you have available multiple tools to do any kind of tests. For instance, you can use PHPUnit for your Test Driven Development (TDD), or Behat if you are following a Behavior Driven Development (BDD).You can do anything: PHP is a modern programming language with multiple applications in the real world. Therefore, only sky is the limit! You can build a GUI application using the GTK extension, or you can create a terminal command with all the required files in a phar archive. The language has no limitations, so anything can be built.Disadvantages
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.
Summary
In this chapter, we looked at how microservices stand against monolithic architecture and SOA. We learned about the essential components of microservices architecture along with its advantages and disadvantages. Further along the chapter, we looked at how to implement the microservices architecture and the prerequisites to take into consideration before switching to microservices. Later, we covered the history of PHP versions along with their advantages and disadvantages.
Chapter 2. Development Environment
In this chapter, we will start building our application based on microservices now that we know why microservices are necessary for the development of our application and the advantages we can enjoy if we base the application on microservices.
The application that we will develop in this book (which is similar to Pokemon GO) is called Finding secrets. This application will be like a game using geolocation to find different secrets around the world. The entire world keeps a lot of hidden secrets and the players will have to find them as soon as possible. There are 100 different kinds of secrets, and they will generate and appear in different parts of the world every day, so the players will be able to find them by walking around different areas and checking to see if there are any kind of secrets nearby.
The secrets will be saved in the application wallet and if the player finds a secret that they already have in their wallet, they will not be able to collect it.
The players will be able to duel against other players if they are close. The duel consists of throwing a dice to get the highest number, and the player who loses will give a random secret to the other player.
In the subsequent chapters, the specific functions will be more detailed, but in this chapter, we only need to know how the applications works in order to have a general overview of the entire application to start building the basic platform based on microservices.
Design and architecture to build the basic platform for microservices
Creating an application based on microservices is not like a monolithic application. For this reason, we have to divide our functionalities into different services. To do this, it is important to follow an adequate design and structure each of the microservices according to its requirements.
The design takes care of dividing the application into logical parts and groups them according to their existing relationship. The architecture takes care of defining which concrete elements support each of the microservices, for example, where the data is stored or the communication between the services.
Throughout the book, we will follow the given structure for each microservice. In the following image, you will see the structure of one of the microservices, the rest of them are similar; however, some parts are optional:
All the requests for our microservices come from a REVERSE PROXY as this allows us to balance the load. Also, we use NGINX as a gateway for the API built in PHP. To reduce the load and increase the performance of PHP and NGINX, we can use a CACHE layer.
In case we need to execute big, resource consuming tasks, or the tasks do not need to be executed in a concrete time window, our API can use a QUEUE system.
In case we need to store some data, our API is responsible for managing the access and saving the data in our DATA STORE.
Note
In this book, we will be using containerization, a new virtualization method which spins ups containers instead of full virtual machines. Each container will have only the minimum resources and software installed to run your application.
We can use Telemetry (it is a system that gets the stats from the container) and autodiscovery (it is a system that helps us to see which containers are working properly) to supervise the container ecosystem.
Requirements to start working on microservices
Now that you understand why you can use PHP (especially the latest release, version 7) for your next project, it is time to talk about other requirements for the success of your microservices project.
