LOADING... Ezlo Innovation

Posts Tagged "tech blog"


Distributed Cloud Architecture: It Shall Not fall

by admin

Mission-critical services

It is said that the strength of a chain is given by the weakest link … this has never been more true than in the world of mission-critical cloud services. 

But what is actually a cloud service? Typically any service made available to users via the Internet from a cloud computing provider’s servers fit this definition. Mission critical cloud services simply have one additional requirement: they have to work no matter what is happening with any underlying server architecture. 

In the following lines we are going to do an anatomy of the cloud services from the perspective of redundancy and failover.

Dreaded Single Point of Failure (SPOF)

Typical architecture of a cloud service consist of several layers:

Hardware layer

Infrastructure layer

Application layer

Each layer consists of multiple components with specific role for each layer and their malfunction can have various effects from performance penalties to complete failure of the service, in which case the component becomes Single Point of Failure. For mission critical services having any SPOF is not an option.

Rule number one in this context is that anything can and will fail, so rather than trying to design components to never fail (which is proven to be almost impossible), we leave them to fail in a controlled manner and have other components take over their role to sustain the service. 

Monolithic approach versus microservices

A typical monolithic application consists of a large application which includes multiple services deployed on a pair of identical servers behind a load balancer. In such case, although the complexity of the solution will be lower, there are multiple Single Points of Failure: one heavy loaded service can cause overhead on both servers which can lead to lost or delayed messages, failures in hardware or infrastructure layer are not fault-tolerant, database can fail or can have heavy performance penalty which are not acceptable for mission-critical services. 

Scalability is also an issue as large, monolithic applications require more time to prepare and deploy, which hurt the ability to do dynamic scaling depending on load.

A much better approach which also solves all these issues is migration to containerized microservices with automatic scaling, distributed across multiple physical or virtual servers. A spike of the requests to a service cannot cause overhead on the entire server anymore, as the load will be distributed to multiple instances of the service and the cloud manager will actually spawn more instances if needed.

Hardware and infrastructure layers

At the bottom of any cloud service are the machines which provide the processing power for the service as well as network infrastructure needed in order to operate. They can consist of physical machines deployed in data centers or they can be virtual machines from a 3rd party provider. 

Which one is better, which one can fail? Well … remember rule number one: both of them can fail, no matter if there are state-of-the-art physical servers in the most modern data center, or the best 3rd party provider, they can have outages which can become Single Point of Failure for your services.

How do we prevent that? 

The keyword is distribution of the hardware and infrastructure on multiple providers and zones, so even a global event affecting entire data center won’t disrupt the functionality of your service.

Application layer

The software components of your application typically consist from a sum of 3rd party tools and frameworks (like web server, database, messaging queues, storage services etc) glued together by your own custom code. 

How can we make sure they don’t fail? We don’t … we actually allow them to fail, so other components take over their role to perform the job. 

How do we actually do that? The keyword is containerization with automatic management, so our applications are encapsulated in Docker containers and distributed using Kubernetes. 

This assure both automatic scalability of the platform as Kubernetes can run more containers when load is high or stop them when are not needed anymore, allowing better cost control of the infrastructure.

The 3rd party components which we rely upon have their own mechanisms of failover and redundancy built on the same concepts as our entire architecture to assure high availability, scalability and performance.



Using VueJS/Nativescript for rapid development

by admin

It’s an on-demand world. And for growing businesses, velocity is one of the most important indicators of potential success. This is true at Ezlo, as well. Our innovation pipeline is filled with projects that need attention, and since time is a limited quantity, we are always looking for ways to speed up our development process.

One way we’ve done so recently, is to adopt VueJS/Nativescript for our new mobile application. Our iOS and Android teams were working hard to build features in our current app to support our customers, so we sought a way to support our customers and evolve our platform at the same time. 

Our answer? Nativescript. Nativescript is a complex open source framework developed by Telerik, in which you can build truly native mobile apps with Angular, Vue.js Typescript or Javascript. One of the biggest advantages of this techdnology is that you only need front-end developers that can work with JS libraries, while they familiarize themselves with Nativescript syntax/docs.

By using Nativescript you can write your code for the application just once, with the result being two applications—one for Android and one for iOS. 

Here are the top four reasons why we chose it:

1) The app uses native components which add to the overall performance of the app. NativeScript-Vue lets us access the native APIs, so we are never really constrained by the framework and we can avoid using third-party modules. If we need, we can just dive into the native APIs without leaving our environment and language. And the code-sharing for iOS, Android, and the Web lets us build once without using assistance libraries.

2) With NativeScript + Vue, you can use JS, TS, or Coffeescript for logic, and you can use HTML, Pug, EJS for templates. CSS/SASS/Less/Stylus for styling. 

3)  Vue has its own DevTools, which come in the form of a browser extension. DevTools simplify application debugging and checking the state and hierarchy of components. They allow you to live-edit your app, track custom events, and time-travel debug your app to see previous versions and the changes made. 

4)  The syntax is familiar. Users of Vue.js will be right at home, and others can access Android SDK’s Java classes and iOS SDK’s Obj-C classes directly from Javascript. 

Taken together, these benefits result in a rapid workflow. You don’t have to learn new languages and there’s a preview mode for iOS and Android that remove the need to install emulators in order to see your application in progress. For any issues we did encounter along  the way, we made use of a robust Slack community and online tutorials.  

Our application is currently in progress while our dedicated iOS and Android teams improve the current future set for our customer base. We’ll be building in those features, as well. Stay tuned for an update when everything is complete.