EC2 Instances

EC2 instantes are the equivalent of Amazon AWS for Virtual Servers offering the biggest set of possibilities to combine CPU, RAM and a separate storage alternatives from small sizes just to process to instances dedicated to storage and data management.

Also AWS provide a robust framework to manage network access and network configuration with possibility to create subnets to separate business areas in the same account and protect data, also using a firewall out of the box reducing the impact of DoS attacks and reusing rules with small effort.

Allocation of public IP addresses and DNS management is simple and add a lot of value to the final solution.

In network space, AWS offer the posibility to create virtual private networks, that act like a private cloud to communicate and protect in different stages the servers created as EC2 instances, an excellent usage of this concept of virtual networks is to create separate environments for SIT, UAT and Production, in order to avoid mixes that could affect the final result in production environments.

Other awesome feature that offera EC2 is the posibility to create templates of a particular instance, this feature, could be use as an alternative to easy create servers to solve particular problems that let you escalate horizontaly, adding more instances to process a big load of information, also AWS offers especialized load balancing services called Elastic Load Balancing, that let you manage multiples instances to according with the load received and being billed using the low cost instances alternatives.

The EC2 instances combined with the other services of AWS cloud let design a top end solution to cover almost all business requirements, giving infinite power to manage intricate business logic and non functional requirements.

EC2 offers a practical set of billing schemas that help the customers, developers, students and bloggers use the platform without fell that are paying to much for it.

• On demand instances billed by hour is a good solution for projects that are starting and need to setup development, testing and first versions of production environments.
• Spot instances that let use take advantage of off pike times and low cost platform to process high volumes of information paying lower rates is simple to manage and implement.
• Long term instances could manage contracts with and without upfront payments for more than 1 year ideal for production environments of applications already established.

EC2 is equivalent to Google virtual servers or Digital Ocean droplets, in my perspective, AWS EC2 Instances are more flexible and powerfull than the other ones because shows a clear separation between the processing unit and the storage.

Why split your application in microservices?

Why we need to split the logic?

When a nontechnical person things in an application, he visualizes it as an engine to solve a problem in the company in order to generate money, this monolithic concept is widely propagated across business managers and business owners. It's not wrong, because in order to generate profit, all of the parts should act as one big application, however, the different components should be synchronized and run in a coordinate way. The ability to align those multiple parts is responsibility of the enterprise architects who has to understand the view of the managers/owners that are receiving the profit of the engine and is paying to keep it running in a effective way.

In business side, every day the drivers are changing and the company should adapt to those new drivers smoothly and promptly without loose control over the process and ideally reducing cost and increasing quality. The implementation of each change should be performed in all parts of the company, including applications, and it's better if the applications are modular and easy to assembly returning to the original best practice to have loosely coupled software components, reducing the dependencies between the components and making easy to replace or update one component in the big structure.

In order to reach this model, each task identified on the company, should be implemented as a service and must run independently of the other components, at this point, it's very important to have defined the input, output and exception management of the task that the service will represent, each service will receive a set of parameters and will execute a process to transform the parameters in an output following a deterministic process. Also, the service could generate an action over information, such as write a file, send an email, modify information in a database or over any other resources available in the platform. When you have to update a process due to a new requirement from the business, you have change just the services that are covering tasks that are impacted for this change, trying to keep the input, output and exception process according with the original, if it's not possible, it should modify just an small part of the communication. 

Also, each component should run in an independent environment, allocating his own resources and avoiding coalitions with other task, in the same way, it could be run using a pool of resources able to run a lot of instances of the same task in parallel without mixing data or fighting for resources; in older architectures models this could be solved with a finite pool of instance of the same component pre loaded, this concept solved a lot of issues but it fails when the pooled instances run out of resources and finally generates a crash in the components. In new architectures based in cloud you could configure unlimited instances on-demand that will be instantiated as soon as are invoked. Those instances should not generate any consumption of resources meanwhile it's idle and also doesn't generate any cost to the company.

To communicate micro services we have to establish a common language to move information between the components, usually, this language requeries to identify the main entities that are playing inside the company processes and generate a detailed documentation of each one, taking care of all the posible stages and all the views that could have each entity.

Micro services must be coordinated by an orquestation process that knows all the capabilities of each service and manage the business logic to generate value to the user, this process act a workflow engine with all the steps and conditions requeried to process a business job with all the exceptions and variations.