Blog
- Details
- Written by R. Elizondo
- Category: Distributed Systems within an Organization
Intro.
The most common scenario in all Organizations is that the people in charge of approving this or that, doesn't have a deep understanding of Computer Systems, and for them, is just a matter of hiring a couple of new devs with the purpose of doing some refactoring here and there, and maybe adding more power to the servers where these apps are running, like going from 2 virtual cores to 4 vCores and maybe from 2GB Ram to 4GB Ram.
So, it is crucial for the CTO or the people in charge of the IT Department, to convince the CEO and/or the members of the board, that not taking action or not taking a real serious action, will cost much more in the long run.
In my experience, the first thing that need to be done, if no one in the company has a clear knowledge of this, is to hire an IT Consulting firm, a proven experienced Architect or at least, taking in account the recommendations posted here.
If your Company fits in the Category of micro to small, the best recommendation is to use third party turn key solutions, like Intuit, Shopify, Wordpress, Wixx, etc. unless you have very special business requirements that would make it hard to handle by any of these.
First things to be considered in distributing systems.
Read more: Key aspects to determine how to distribute a system
- Details
- Written by R. Elizondo
- Category: Distributed Systems within an Organization
Service Oriented Architecture is a Software Design Pattern that allows you to Distribute a System into smaller more manageable Applications. In this pattern the big monolithic system is split into domain based units called Services.
Each Service is independent from the other, and they communicate between each other by some sort of REST Api calls.
The common part here is that all of them share the same Database, where each one has its own schema. This way, each service can scale differently in terms of application layer, while maintaining only one Database Server.
There are many variants to this pattern, one is shown in the figure above, where the users can make requests to each one of these Services. If the called Service requires anything from other, it can make a call to it.
This pattern is recommended for decomposing a big Monolithic System, and for the sake of development costs, i recommend to use the same Stack for all Services, in my case I work with Nginx as Web Server and PHP as Backend Language.
Its also, very simple to add a common Nginx Ingress Server to act as Load Balancer and prevent possible malicious attacks, filtering only allowed incoming requests from whitelisted IPs, or special headers, etc. and I'd recommend for the long run to consider to put these Services in Docker containers and use Kubernetes as Container Orchestrator.
With Kubernetes is fairly simple to implement and maintain a pool of Services for the whole CI/CD Pipelines. Just imagine that this monolith got broken into 5 Services, now for each one, you will need a local environment where the developers will be working, then a Dev environment where the work of each team will be joined and unit, integration and functional testing will be executed, then a QA Environment where Q&A team will be testing each single use case to make sure everything continues working fine, then a Stage Environment that has the same nmber of replicas with the exact same data as in Production, where a round of key testing is done, and then Production Environment.
So if we consider one container for each one of these Services, and assuming you have no more than 3 replicas per service in Stage and in Production, plus the Sql proxy ones to connect to the DB, plus backup services, log and monitoring, etc. most likely for these 5 Services, you will end having a Kubernetes cluster with around 100 deployments.
A typical Kubernetes cluster for a 5 Service workload, with this configuration, will require you to consider a virtual environment capable of providing 10 to 30 virtual cores and 20 to 40 GB Ram divided into at least 5 to 10 nodes.
A typical Kubernetes Engine for a workload as mentioned above with a Cloud SQL DB up to 100 GB no HA in Google Cloud may be in the range of US $500 ~ 1,000 per month.
The benefits of using a cloud provider like Google Cloud for a Kubernetes Cluster, is that you can be up and running in no time and you have tech support available all the time.
Next Up: Microservices Architecture
- Details
- Written by R. Elizondo
- Category: Symfony Framework
The most easy and fast way to install Symfony is this:
Open a SSH Terminal to the machine where you want to make this installation (You may want to check these recipes if you need to get up and running a Virtual Machine with a LEMP Stack and Composer).
Go to the directory where you want a fresh new Symfony project and just type
composer create-project symfony/skeleton:"^5.4" cool_projectinstead of 5.4 you may use newer versions, currently 6.0, 6.1, 6.2, 6.3
if you decide to install most recent 6.* versions, you better have PHP 8.* up and running, as many Symfony 6.* components are no fully compatible with older versions of PHP
Notice: Keep in mind that you need that the folder where you are installing the Symfony project to be writable.
once done you should be seeing something like this:
Read more: How to install Symfony Framework using composer in 2 easy steps
- Details
- Written by R. Elizondo
- Category: Symfony Framework
In the Symfony Framework, a listener is a class that listens to a specific event and executes a specific code when that event occurs. Listeners are used extensively in Symfony to implement various functionalities in a decoupled and reusable way.
Listeners are part of Symfony's event-driven architecture, where events are dispatched and listeners are registered to handle those events. When an event is dispatched, all registered listeners for that event are called in the order of their priority (which can be set when registering the listener), and each listener can execute its own code to respond to the event.
Listeners can be implemented in different ways in Symfony, depending on the context and the use case. Some examples of listeners in Symfony include:
- Kernel event listeners: These listeners are used to handle events related to the Symfony kernel, such as the request, response, exception, and termination events. Kernel event listeners can be used to modify the behavior of the Symfony kernel, add custom functionality to the application, or handle errors and exceptions in a centralized way.
- Doctrine event listeners: These listeners are used to handle events related to Doctrine, such as the prePersist, postPersist, preUpdate, postUpdate, preRemove, and postRemove events. Doctrine event listeners can be used to execute custom code before or after a specific Doctrine operation, validate or transform data, or implement custom business logic.
- Form event listeners: These listeners are used to handle events related to Symfony forms, such as the preSubmit, postSubmit, preSetData, and postSetData events. Form event listeners can be used to modify the form data, validate the form input, or execute custom code before or after the form submission.
Overall, listeners are a powerful and flexible mechanism in Symfony that enable developers to implement complex functionalities in a modular and extensible way.
Further reading:
Page 1 of 42