- Kingland Platform
As the complexity and size of software grows, we sometimes run into conflicting dependencies that can increase the cost and lower the quality of a solution for a potential client. Fortunately, using modern software architecture principles, the Kingland Platform sidesteps this problem by using Containers, and we maintain a competitive edge by passing on our savings to our clients.
Before we jump in to the Kingland solution, it helps to look at a similar albeit less abstract example of the same problem. In the 1930s comedians Abbott and Costello had a bit about three baseball players nicknamed "Who", "What", and "I Don't Know." Watching the game, Costello would ask "Who's on first?"
In every day English we rarely come across situations where an overloaded word obfuscates the meaning of a sentence or a conversation. However, in software such situations arise frequently with the names of dependencies, and if not handled correctly such dependencies can greatly increase the cost and complexity of your customized software solution. For example, perhaps your project uses legacy software that relies on Python 2.x, but on the same machine you want to use Machine Learning software that requires Python 3.x. Naively, one might assume that "python" cannot refer to both Python 2.x and Python 3.x on the same machine, just as one cannot use "Who" as both a pronoun and a proper noun.
Here is where we can use containers. A container works a lot like a virtual machine. It simulates a virtual environment by abstracting away a software's environment from its host machine. However, virtual machines take a long time to start up (sometimes minutes), and each virtual machine can take up gigabytes of hard drive space and memory. In contrast, containers take up 10s-100s of megabytes and can start up in seconds. Their size and speed make deploying hundreds to thousands of them to the cloud desirable from a cost perspective. This feat is impossible with clunky virtual machines.
Yet we still get all of the benefits of a virtual machine. Containers help us create custom, virtual environments for every component or microservice that we want to run. As mentioned in previous posts, we use microservices to help modularize and scale our deployments, which has made our software more robust. Containers help us maintain our microservices by keeping our microservices and their environments separate from each other, isolated such that we never need to worry about conflicting dependencies. Containers even provide a fast and consistent environment for developers who may be running many different Operating Systems. This means that our clients get solutions faster and with higher quality than they would with other companies that do not rely on containers. Furthermore, because of containers, software becomes more fault tolerant, leading to less down time when compared to other non-container projects.
In summary, with Containers you get:
If you want to move your projects out of the 1930s and if you want your projects buttressed by modern microservices using containers, contact us to learn more.