Synergy Platform

Hello dear reader !

(English version)

You want to know what is Synergy Platform? To whom is intended? What is so special about it? Behind this fancy name is Enterprise Level System suited for deployment and running Reactive applications for customers which demand that system must be available 24/7. This demand is obvious: if system doesn’t work, customer looses money!

New requirements demand new technologies. Today solutions emphasize managed servers and containers. Scaling is achieved through buying larger servers and concurrent processing via multi-threading. Additional servers are added through complex, inefficient and expensive proprietary solutions.

But now a new architecture has evolved to let developers conceptualize and build applications that satisfy today’s demands. We call these applications Reactive Applications. This architecture allows developers to build systems that are event-driven, scalable, resilient and responsive: delivering highly responsive user experiences with a real-time feel, backed by a scalable and resilient application stack, ready to be deployed on multi-core and cloud computing architectures.

The Reactive Manifesto describes these critical traits which are needed for going reactive. While there are dependencies between them, these traits are not like tiers in a standard layered application architecture sense. Instead they describe design properties that apply across the whole technology stack.Event-Driven: Enables parallel, asynchronous processing of messages or events with ease. Application that is under heavy load can thus have lower latency and higher throughput than a traditional application based on blocking synchronization and communication primitives. This results in lower operational costs, increased utilization and happier end-users.

  1. Event-Driven: Enables parallel, asynchronous processing of messages or events with ease. Application that is under heavy load can thus have lower latency and higher throughput than a traditional application based on blocking synchronization and communication primitives. This results in lower operational costs, increased utilization and happier end-users.

  2. Scalable: A scalable application is able to be expanded according to its usage. This can be achieved by adding elasticity to the application, the option of being able to scale out or in (add or remove nodes) on demand. In addition, the architecture makes it easy to scale up or down (deploying on a node with more or fewer CPUs) without redesigning or rewriting the application. Elasticity makes it possible to minimize the cost of operating applications in a cloud computing environment.

  3. Resilient: The ability to recover and repair itself automatically in order to provide seamless business continuity. Traditional fault handling cannot achieve this because it is defensive in the small and too aggressive in the large—you either handle exceptions right where and when they happen or you initiate a failover of the whole application instance.

  4. Responsive: Rich and engaging applications that provide instant feedback based on user interactions and other stimuli. This makes them more efficient, creates a feel of being connected and equipped to solve problems and accomplish tasks. One example is Google Docs which enables users to edit documents collaboratively, in real-time—allowing them to see each other’s edits and comments live, as they are made.

It is clear that new programming paradigms and tools need to be embraced in order to deliver on the multiple levels of sophistication required to deliver these Reactive applications. Finance and telecommunication were the first to adopt new practices to satisfy the new requirements and others have followed. Open Source Osijek Community strongly supports Reactive path and believes that this paradigm can be used by small and middle size software companies which do not have to much money and want to scale up.

What hardware resources are used by Open Source Osijek Community ?

Osijek business center BIOS has granted our community free hardware resources. The plan is to use it for educational purposes and development of Synergy Platform. For development purposes four ProxMox Linux Containers are used on one physical machine. It is not the best solution to have all linux containers on one physical machine but for now it is good enough. In near future one more physical machine will be added.

Synergy_platform_hardware
Fig1. – Synergy Platform Hardware

How Synergy Platform architecture looks like ?

Synergy Platform is composed from several components necessary for building High Availability (HA) services.

Synergy_platform_overview
Fig2. – Synergy Platform architecture

 

List of components:

  1. Linux Centos – linux distribution which focus on stability, predictability, and security.

  2. MariaDB Galera Cluster – MariaDB Galera Cluster is a synchronous multi-master cluster for MariaDB with synchronous data replication and active-active multi-master topology.

  3. Redis – advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. Most typical use-case: cache frequently accessed data in-memory, often in front of a database. Who’s using Redis? Twitter , Github, Weibo, Pinterest, Snapchat, Craigslist, Digg, StackOverflow, Flickr and many others.

  4. Spray – fully asynchronous HTTP server which can handle thousands of concurrent connections. It also supports request and response streaming, HTTP pipelining and SSL. It has elegant DSL for API construction which is quite unique.

  5. HAProxy – TCP/HTTP load balancer commonly used to improve the performance of web sites and services by spreading requests across multiple servers. It is written in C and has a reputation for being fast, efficient (in terms of processor and memory usage) and stable. It is used by a number of high-profile websites including Stack Overflow, Reddit, Tumblr, and Twitter and is used in the OpsWorks product from Amazon Web Services.

  6. Reactive applications powered by Akka Toolkit – Akka is used for building highly concurrent, distributed, and fault tolerant event-driven applications on the JVM (Java Virtual Machine). It has excellent properties: simple concurrency and distribution, resilient by design (self-heal), high performance (millions msg/sec on a single machine and small memory footprint), adaptive load balancing, routing, partitioning and configuration-driven remoting.

  7. Play WebFramework – it is just a presentation component which serves users as front-end window to their business logic. It is used as glue between HAProxy load balancer and Spray HTTP server. This means that Play uses only HTTP to communicate with Reactive Applications. We could say that Play is “thin-client”.

  8. ProxMox – virtualization management solution, based on KVM virtualization and containers. It manages virtual machines, storage, virtualized networks, and HA Clustering.

Now, when a reader reads this list of features he/she will probably say: “Hey, this is not special. I can use JBoss Application Framework, Spring, Tomcat, Microsoft .NET Framework, MySQL, PostgreSQL,… and achieve the same enterprise level system quality and loose coupling between services with any of these technologies”. My answer to this is: “Building distributed, high performance and event-driven applications is HARD. It is not something which comes out-off-box with standard frameworks. Don’t get me wrong, most of frameworks are sufficient for standard projects (standard project = applications are running on single node). But if you need balanced load distribution over all cluster nodes and guaranteed automatic fail-over of applications then you have to build the goddamn system by yourself. This is how it is done in industry where every minute of off-line system or degradation in performance is lost of money. Industry pays for this kind of systems with great money and have big expectations. One of goals of Open Source Osijek Community is to show how to build simplified version of highly available and redundant system. Our Synergy Platform (version 1) will be mostly suited for projects where the most frequent business process flow is: client request → server back-end → read/write something from/to database.

What are we doing currently?

In June, 2014 we will be testing the last missing link for our platform – Redis: In-memory key-value store.

Meanwhile, when I steal some time I will study and try Docker application container which could help us to distribute Reactive Applications flexibly and to have the same environment on developer computer and production system.

ps. Translation to Croatian language is comming soon…