Eldarion Leverages CoreOS To Rebuild Its Gondor PaaS Product
Eldarion uses Python and Django for Web application development for clients such as Bosch, AOL, and the Cox Media Group. “We work with organizations around the world in a range of industries and sizes, from large enterprises to entrepreneurs,” says James Tauber, founder, CEO and CTO, Eldarion.
Eldarion initially developed Gondor as a Django Web Framework tool. As such a tool, Gondor sped development by team members who were tasked anywhere in the development lifecycle.
Eldarion selected Python, which it already used religiously to build Gondor. “It made sense for us to build that first version of Gondor using the technologies that we found most familiar. The new version of Gondor makes considerable use of the Go programming language,” explains Tauber.
The Go open source programming language supports Language and Locale Matching, which selects the best human language to use / render for the reader based on an intersection between the languages the Web application supports and those that are the user’s preference.
Eldarion leveraged CoreOS to rebuild Gondor in order to run it on technologies from alternative infrastructure providers and in private clouds. By untying Gondor from a single infrastructure provider, Eldarion met its customers’ business continuity (BC) and redundancy needs.
Gondor users code complicated Web tools and applications using technologies that are continually blossoming in new ways. Users support applications on complex and highly scalable infrastructures. “There are stronger requirements for frontend technologies such as React and Angular, which present new challenges in order for the backend to cope with stateful data,” explains Tauber.
The previous iteration of Gondor did not meet the design constraints necessary to in order for it to work with micro service architectures. The older Gondor platform operated based on infrastructure assumptions that don’t facilitate the kinds of uses Eldarion customers now have in mind. Eldarion had to adapt its approaches to Gondor development to support its customers’ needs moving forward.
Tools In Gondor’s Tool Belt
Gondor counts on the CoreOS Linux distribution as well as its tools Flannel and etcd. Gondor makes heavy use of Kubernetes.
“We chose CoreOS because of the container focus. CoreOS designed its distribution for distributed systems and a strong security update policy. We rely on this to ensure our customers’ are running on a secure platform,” says Tauber.
Gondor uses Flannel to provide the tools necessary to maintain a flat network on the Gondor cluster. This helps Gondor to scale efficiently through load balancing. The flat network that Flannel enables lets containers talk to each regardless of network location.
Using etcd, Eldarion enables Gondor with service discovery and consensus handling. “When we consult with etcd about a lock, we can ensure that it handles consensus so that we maintain high availability and consistent state, which are crucial for distributed systems; Kubernetes also uses etcd, to provide discovery of services through the Domain Name System add-on,” explains Tauber.
Gondor uses Kubernetes to perform scheduling on clusters while accounting for individual node resource usage. “This is important for making proper scheduling decisions,” says Tauber.
Eldarion prototyped Gondor components on Kubernetes in support of its investment in building Gondor on containers. “Some changes were made to support communicating with the Kubernetes API, which fit perfectly into the model of how we wanted to design our clusters,” says Tauber.
“Kubernetes’ native capabilities resolved gaps that exist in a pure CoreOS solution,” says Tauber. Eldarion uses Kubernetes services and replication controllers to ensure that customer sites scale across Gondor clusters and provide for zero downtime deployments.
“Replication controllers give Eldarion a guarantee that if Gondor requests N pods of a Gondor service that N will always be running somewhere. Combining that with Kubernetes services, Eldarion can expect that regardless of where those N pods are provisioned, there is a stable IP to communicate with them from anywhere else in the cluster,” says Tauber.