Laravel Microservices or Lumen vs Laravel

«Microservices» or «microservice architectural style» is an approach to developing a single application as a suite of small parts – services accessed through APIs - as opposed to «monolithic architectural style» when an application is built as a single unit. It allows different microservices to be written in different programming languages, and they can also be managed by different teams. When is it a good idea to use this architecture in custom software development and how Lumen can help to build microservices?

Contact us to learn how our Laravel consultants and programmers could help you with Laravel Microservices.

Figure. Example of Microservices Architecture.

Differences between Laravel and Lumen

Lumen microframework is a lightweight version of Laravel full-stack framework. Lumen use the Laravel syntax and components, and can be 'upgrade' easily to Laravel.

Lumen is a more specialized (and stripped-down) framework designed for Microservices and API development. So, some of the features in Laravel such as HTTP sessions, cookies, and templating are not needed and Lumen takes them away, keeping what's essential - routing, logging, caching, queues, validation, error handling and a couple of others.

As Taylor Otwell, the main creator and maintainer of the Laravel and Lumen frameworks, underlined in his interview: “Lumen opts for maximum speed. The actual Lumen framework repository is probably only a dozen files or so. The rest is made up of the Illuminate components. This allowed me to flesh out the features of the framework very quickly, though it did take me three or four iterations to find a solution that was really, really fast while still providing very powerful features”.

Taylor Otwell also talked about one more key difference: «The entire bootstrap process is also located basically in a single file, which is less configurable overall than full-stack Laravel, but for small microservices and APIs that are mainly interested in speed it's a good trade-off».

Additionally, Lumen uses a faster router than Laravel (FastRoute instead of Symfony’s) and many features are disabled by default in Lumen in comparison with Laravel, for example, Facades, Dotenv environment files, Eloquent and so on.

Microservices need to possess the ability to read and write to a database, must be secured, be built with the so-called message-driven approach, and have the ability to provide reports. Modern microframeworks make these tasks as trivial as possible.

Lumen is the perfect solution for building microservices. It utilizes all benefits of Laravel framework including security, easy database configuration (MySQL, Postgres, SQLite, and SQL Server), queue service configuration, integration with reporting tools and so on.

Lumen microservices architecture example

Let’s imagine a standard web page on an ecommerce website. To pull together the various parts of that website, we might need several microservices. One of them might display the details about the product being offered for sale. Another might show the price and stock level. And we’ll probably be showing shopping cart contents too, which may be another microservice.

If the shopping cart service is unavailable, we’re probably in a lot of trouble, but we could still show the web page with the listing. Perhaps we just hide the shopping cart or replace it with an icon saying “Will Be Back Soon!” or replace the part of the UI containing the cart control with a phone number for placing an order.

RESTful API Development with Lumen (Laravel) Microframework

API is an approach that allows different applications or different parts of a single application to share data among each other by special programming commands. By default, an application has no use for APIs if it is not defined by software requirements. When a customer orders an API creation from us and they want to go with Laravel Development then we usually suggest the use of Lumen. When is it necessary to develop an API for the application and why do we choose Lumen for this?

For any API service, speed is very important, because if it is not able to serve a lot of requests per second fast, the business perspectives of using the API will be much reduced.

As we considered earlier, API development can be done using fast microframeworks like Lumen, which is one of the fastest PHP micro-frameworks available.

• Lumen microframework can be used to build an API for a web application to integrate it with a mobile application. Simple example: a mobile bookstore application offers a search feature, where the user can look for books by author name. The mobile application needs to use an API, which should be provided by a bookstore web service, to get data about authors and books.
• Lumen microframework can be used to build an API for integrating different microservices within a large service/application (core project). For example, a core web application helps to order stuff from local, offline stores/partners. Each of these stores/services come with their own APIs. The right development approach is to create a microservice, which will call the APIs of the partners and provide its own API to transfer data received from partners to the core web application.

The most popular open source APIs created using Lumen are located on github.com.

Which tool to use – a full-stack framework like Laravel or a microframework like Lumen – depends on software requirements and developer competence/experience. Top-notch developers teach: “Use microframework if you are comfortable with making all of your own architecture decisions and full-stack framework if not”. Since large web application can be built based on microservice architecture approach, this means that projects must not be just micro or small to use the microframework.

When it is a good idea to use microservices

According to the software requirements, each web project is reduced to one of the following types:

• Development of an application from scratch;
• Rebuilding (or refactoring) a legacy application;
• Adding new functionality to an existing application.

‘Microservices architectural approach can be used in each of these cases. But often it is used for refactoring (rewriting) a legacy application from monolith into microservices.’

Basically, there are 4 main reasons for it:

• The application is getting so big that developers need a lot of time to understand it, and therefore organizational/project scaling issues are arising;
• The application consists of different parts with independent and very different update&release frequencies;
• There is a necessity to dynamically scale specific parts of the system up and down, independently from the other parts;
• Different parts of the system have specific domain or technical requirements that force developers to use a programming language/framework which is different than the common programming language of the team. 

Business perspectives of microservice architecture

• Protect from failure. In a monolithic service, if the service fails, everything stops working. With a monolithic system, we can run on multiple machines to reduce our chances of failure, but with microservices, we can build systems that can handle the total failure of services. Since services can fail at any time, it's important to be able to detect the issue quickly and, if possible, automatically restore working order. Microservice applications put a lot of emphasis on real-time monitoring, checking both architectural elements (how many requests per second is the database getting) and business-relevant metrics (such as how many orders per minute are received). Semantic monitoring can provide an early warning system of something going wrong that triggers development teams to follow up and investigate. This is one of the main reasons why organizations like Amazon and Netflix use these architectures—to ensure they remove as many impediments to getting software out the door as possible.
• Scalability. A change made to a small part of the monolithic application (scaling), requires scaling of the entire application rather than parts of it which in turn requires greater resources (hidden costs of building the monolithic application). In contrast, microservices are independently scalable. With microservices, developers can make a change to a single service and deploy it (moving from test server to production server) independently of the rest of the system.
• Decreasing team size and their productivity. Microservices help developers minimize the number of people working on each codebase to hit the sweet spot of team size and productivity. Project managers can also shift ownership of services between teams to keep people working on one service collocated. When services are isolated from each other,  much less coordination is needed between service owners. The less coordination needed between teams,  the more autonomy those teams have, as they are able to operate and evolve their services more freely.

Figure. Microservices Architecture is sometimes the best technological solution for business. Source: martinfowler.com/microservices/#what

Examples of projects with microservices architecture

• We used Laravel microservices to create insurance calculator for Insly Company to speed up the quote calculation for brokers who also use this SaaS system. With microservices, it is easy to test API calls and create documentation for new functionality.
• Gilt, an online fashion retailer, started in 2007 as a monolithic application, but by 2009 Gilt’s system was unable to cope with the load being placed on it. By splitting out core parts of its system, Gilt was able to better deal with its traffic spikes, and today has over 450 microservices, each running on a separate machine.
• The Guardian website is another example of an application that was designed and built as a monolith, but has been evolving in a microservice direction. The monolith still is the core of the website, but they prefer to add new features by building microservices that use the monolith's API. This approach is particularly handy for features that are inherently temporary, such as specialized pages to handle a sporting event. Such a part of the website can quickly be put together using rapid development languages, and removed once the event is over. Similar approaches are used at a financial institution where new services are added for a market opportunity and discarded after a few months or even weeks.
• Other examples include Amazon, Netflix, Google, Ebay, the UK Government Digital Service, realestate.com.au, Soundcloud, Forward, and comparethemarket.com.
• Google Maps is an example of a cloud based web application that shares its own functionality through APIs for free, but with some limits, after exceeding which this API functionality becomes paid. Some other great companies such as Ebay provide APIs that help entrepreneurs to make money by integrating their web, desktop or mobile applications with the eBay API platform. As ProgrammableWeb editor-in-chief, David Berlind puts in his blog: ‘For those who understand the potential of APIs, there could be millions of dollars to be made, or saved.’ 

Differences between full-stack and micro web frameworks for building microservices

A web framework is a tool for solving common software development problems fast (read as “cost-effectively”). Web frameworks are divided into full-stack frameworks and microframeworks. 

Web frameworks “allows developers to save time by re-using generic modules in order to focus on other areas”.

As an example, a framework will keep the developer from having to spend 2 or 3 days creating an authentication form (which is not a specific task). The time that is saved can be dedicated to more specific components as well as to the corresponding unit tests; giving the solid, sustainable and high-quality code.

Another example: when working in teams, things can get ugly when it comes to choosing options for libraries and tools. Usually, each member of the team will try to push her/his preferred options. Nevertheless, if the team is using a framework, it can simply use the default options and avoid discussions.

A full-stack framework is a framework that attempts to provide nearly everything — from web serving to database management right down to HTML generation — that a developer could possibly need to build an application. It likely includes components that may not be needed by the majority of applications, but having them available makes it easier to integrate new features.

A microframework is a framework that attempts to provide only the components that are absolutely necessary for a developer to build an application; or it may focus on providing the functionality of one particular area very efficiently. Microframeworks often tend to be better-suited for smaller applications or for applications with specific purposes for which the framework was designed. In the case of web application frameworks, a microframework may be specifically designed for building the so-called APIs for another service or application. Microframeworks often need to be extended with additional components in order to make them provide more functionality.

Source: digitalcommons.uri.edu/cgi/viewcontent.cgi?article=1632&context=theses

A microframework is a collection of bare necessities required to build a web application. Typically, a microframework facilitates receiving an HTTP request, routing the HTTP request to the appropriate controller, dispatching the controller, and returning an HTTP response. Some microframeworks take this a few steps forward and also provide additional tools to manipulate the HTTP response (HTTP caching, status updates, redirects, and so on) as well as a middleware implementation.

Many developers are familiar with larger full-stack frameworks like Laravel or Symfony. These excellent frameworks have a larger codebase, more "kitchen-sink" functionality, but also require more time to learn them. For some projects, both Laravel and Symfony are great tools. For other projects that do not require additional features, microframeworks are a more appropriate tool for the job.