Iron.io Brings AWS Lambda In-House, Settles into Microcontainers
Few technologies have captured the attention of the developer community quite like AWS Lambda, as an increasing number of companies consider the benefits of a serverless architecture, also called stateless computing, for their own services.
“Lambda has helped kick off the conversation, it put a stake in the ground and said ‘This is where we see the world going in regards to architecture and dev environments,” said Chad Arimura, CEO at Iron.io,which has been running an event-driven serverless base since 2009, though the company wasn’t officially founded until 2011.
Iron.io’s customers have been asking for the ability to run Lambda code on Iron.io itself for quite some time. Now, this wish will be granted. Over the next few weeks, Iron.io will release more information about a new service, called IronLambda, which will offer the ability for Lambda code to be run anywhere — Even on AWS.
Arimura notes that Iron.io’s Lambda products will feature an extended strategy to implement protocols, containerize functions, run Lambda functions, import into Iron.io and will run across any infrastructure with flexibility over one’s source code.
Iron.io And AWS Lambda
Initially, Iron.io had gathered interest in its architecture from enterprises looking to embrace serverless computing and break down their monolithic applications into a microservice-based approach. Enterprises that are considering serverless architecture want to have control over their data. Though cloud-based PaaS and SaaS platforms are often heralded as the future of data storage, for companies storing sensitive private information, having a public cloud or an off-premise storage solution isn’t viable. Iron.io packages a multitude of benefits to suit many deployment models.
AWS Lambda Automated Batch Architecture
The initial, beta, version of Iron.io Lambda will only support asynchronous Lambda calls. Synchronous Lambda calls allow for developers to set up a block until a client receives a final response from a service after initiating a direct call, whereas asynchronous functions will pass control to back to the source code after a request has been made.
“Any API gateway or web app for API’s can kick off asynchronous calls on the Iron.io Lambda platform. In the future, we will add synchronous support and routers to build complete microservices out of the box on the Iron.io stack,” said Arimura.
Iron.io Platform Diagram
When working with a variety of use cases, managing one’s microservice infrastructure can quickly become a tangled Web once deploying services at scale. Iron.io seeks to resolve the common pain points associated with breaking up a monolith application by offering a wide variety of packaged products on top of the Iron.io platform built to address the many challenges faced when running services in an enterprise environment.
In addition to the upcoming release of Iron.io Lambda, it offers customers its own IronWorker platform powers streamlined orchestration for containerizing applications and deploying them at scale, with high availability, stack customization, service isolation, and webhooks spanning a multitude of APIs to power a variety of applications.
IronMQ Dashboard
Arimura notes that many enterprises would love to move toward a microservice-based architecture, but that they don’t always know how to chunk off bits and pieces. “We create solutions around data and file processing where if an enterprise has a specific workload in regards to data processing, we can create that, or offer implementation partners to create that,” he said.
Iron.io’s flexible onboarding allows for businesses to move toward embracing microservices without having to face the typical challenges of developing a fully containerized application solution.
Most every enterprise has batch processes. These have the same pattern. We offer an inherent solution by powering a microservices architecture deployed on the Iron.io platform. Unlike other organizations which have the engine, Iron.io gives you car as well so you can start driving,” Arimura said.
Iron.io offerings include an enterprise-level dashboard, individual job control, surfacing analytics, the ability to monitor analytics from a container, and more. Users can start a vast quantity of jobs or containerized services at once, able to gain insights on how many jobs failed, their memory consumption, and overall CPU usage.
The Rise of the Microcontainer
Extracting data can be a daunting task for developers faced with coupling a monolithic database to a microservice-based design. How an organization chooses to approach data processing, extracting, and loading can have significant impacts on its overall operational costs. Iron.io simplifies this by using ETL (extract, transform, load) connectors.
It’s no secret that Iron.io has been driving the emerging microcontainer trend, as developers continue to embrace the concept of making their container-based services have even less of a footprint. “Iron.io launched over 1 billion containers in 2015. We discovered moving things from server to server is inefficient with very large containers. Most are bloated with stuff you’re not using for microservices. You don’t need huge containers, so a lot are shrinking down,” said Arimura.
Task Scheduler in Iron.io
In the beginning, developers often had a one-size-fits-all approach to working with containers. One had a standard set of Docker containers, often forced to run their stack in a particular language, which then had their source code layered onto it. In the end, this solution ended up bloated. Arimura noticed that the ‘standard,’ way of working with containers wasn’t very streamlined, and in many cases was no longer a microcontainer solution at all.
As such, Arimura and the team at Iron.io set out in a new direction, one which allowed their clients to self-contain their individual workers. As a result of embracing this new direction, Iron.io developed the concept of microcontainers, offering their users a set of individualized building blocks which would allow for them to build custom containers to support their own stack, regardless of what it was running on. Arimura notes that the natural evolution of this concept has seen customers using originally Iron.io specific containers for projects, to using their own containers to build microservices.
It is Iron.io’s goal that if a team can package a project, it can be run on the Iron.io platform. As such, they are much more than simply a platform to run Docker containers or even to orchestrate microservices. They want to set the stage for deploying containers globally at scale anytime, anywhere.
Feature Image: Locomotive yard, Ballinamore, Ireland, 1959, from the National Library of Ireland.
