Love them or hate them, containers have become part of the infrastructure running just about everything. From Kubernetes to Docker, almost everyone has their version of containers. The most commonly used is still Docker. IronWorker was among the very first to combine serverless management with containers. In this article we will give a high-level overview of what a Docker image is, and how IronWorker uses them.
So, What is a Docker image?
To start, we need to have an understanding of the Docker nomenclature and environment. There is still not a clear consensus on terms in regards to containers. What Docker calls one thing, Google calls another, and so on. We will only focus on Docker here. (for more on Docker vs Kubernetes, read here).
Docker has three main components that we should know about in relation to IronWorker:
1) Docker File
Let’s keep it simple. Docker files are configuration files that “tell” Docker images what to install, update, etc. Basically the Docker file says what to build that will be the Docker image.
2) Docker Image
A Docker image is the set of processes outlined in the Docker file. It is helpful to think of these as templates created by the Docker files. These are arranged in layers automatically. Each layer is dependent on the layer below it. Each layer then becomes more abstracted than the layer below.
By abstracting the actual “instructions” (remember the Docker files?), an environment that can function with its resources isolated is created. While virtual machines relied on calling OS level resources, containers have eliminated this. In turn, this creates a lightweight and highly scalable system. IronWorker takes these images and begins the process of creating and orchestrating complete containers. What exactly is the difference between a Docker image and a Docker container? Let’s see.
3) Docker Containers
Finally we come to the containers. To simplify, we can say that when a Docker image is instantiated it becomes a container. By creating an instance that draws on system resources like memory, the container begins to carry out whatever processes are together within the container. While separate image layers may have different purposes, Docker containers are formed to carry out single, specific tasks. We can think of a bee vs. a beehive. Individual workers carry out asynchronous tasks to achieve a single goal. In short, containers are packages which hold all of the required dependencies to run an application.
After the container has been run, The Docker image is inert and inactive. This is because Docker image has carried out its purpose and now serves only as a meta reference.
IronWorker and Docker
So, you have your containers configured and everything is ready to go. What next? While Docker containers can function on their own, things like scaling workloads is much faster, more reliable, and easier with an orchestrator. IronWorker is one such container orchestrator, with some unique properties.
An orchestrator adds another layer of abstraction to implementing and running containers. This has become known as “serverless” in recent years. While there is no such thing as a truly serverless, the term simply means there is no server management involved. By this point in the configuration, we have likely all but forgot about our original Docker image.
Forgetting about managing a server to react to spikes in traffic or other processing needs greatly simplifies a developer’s job. Tasks and other processes are scaled automatically. At the same time this allows for detailed analytics. Because the containers are managed by IronWorker, whether they are short lived or take days, the jobs are completed with minimal developer input after the initial setup.
What about migrating to other clouds or on-premise?
Traditionally, containers have been cloud based. As new options develop beyond just Amazon Web Services, the need to deploy flexible tools increases. Obviously devops changes frequently. Sometimes it even changes daily. One of the key benefits to IronWorker is that exporting your settings (as Docker images) and continuing on, either redundantly or in new iterations, in varying environments is the easiest in the marketplace. This includes deploying fully on-premise. This ability to maintain freedom from vendor lock-in and future needs is what separates IronWorker from the rest.
If your business uses cloud computing–as most businesses do these days–it’s very likely that you have at least one public cloud solution. Ninety-one percent of organizations have adopted the public cloud. What’s more, a full half of large enterprises now spend more than $1.2 million every year on their public cloud deployments.
The “public cloud” refers to cloud computing services such as storage, software, and virtual machines that are provided by third parties over the internet. Some of the biggest public cloud providers are Amazon Web Services, Microsoft Azure, and Google Cloud Platform.
Increasingly, however, companies are growing interested in a “cloud agnostic” strategy. So what does “cloud agnostic” mean, and how can your own business be cloud agnostic?
This article has all the answers.
Cloud Agnostic: Definition and Examples
One of the greatest benefits of cloud computing is its flexibility. If you’re running out of storage, for example, your public cloud solution can automatically scale it up for you so that your operations will continue seamlessly.
Being “cloud agnostic” takes this idea of the flexible cloud one step further. As the name suggests, cloud agnostic organizations are those capable of easily running their workloads and applications within any public cloud.
The fact that an organization is “cloud agnostic” doesn’t mean that it’s completely indifferent as to which cloud provider it uses for which workloads. Indeed, the organization will likely have established preferences for their cloud setup, based on factors such as price, region, and the offerings from each provider.
Rather, being cloud agnostic means that you’re capable of switching tracks to a different public cloud provider should the need arise, with minimal hiccups and disruption to your business.
Why Do Companies Want to Be Cloud Agnostic?
It’s hardly surprising that more companies are looking to be cloud agnostic, given that 84 percent of enterprises now use a multi-cloud strategy. This involves using two or more public cloud solutions, allowing you to take advantage of the differentials in features or prices between providers.
Another reason that companies want to be cloud agnostic is to avoid vendor lock-in. Cloud computing has revolutionized the ways that companies do business. It does so by giving them access to more products and services without having to support and maintain their own hardware and infrastructure. However, this increased reliance on cloud computing also comes with the risk of dependency.
Management consulting firm Bain & Company finds that 22 percent of companies see vendor lock-in as one of their top concerns about the cloud. “Vendor lock-in” is a phenomenon when a business becomes overly dependent on products or services from one of its vendors. This is highly dangerous if the vendor hikes its prices, stops providing a certain offering, or even ceases operations.
The world of cloud computing is rife with vendor lock-in horror stories. One example is that of Nirvanix, a cloud storage firm that went out of business and gave clients only two weeks to move their data. While it might seem impossible for an Amazon or Google to go out of business, remembering companies like AOL show that it’s not completely unrealistic for a vendor to cut services. By making your company more flexible and adaptable, being cloud agnostic inoculates against the risk of vendor lock-in.
Cloud Agnostic: Pros and Cons
The Pros of Being Cloud Agnostic
No vendor lock-in: As mentioned above, being cloud agnostic makes the risk of vendor lock-in much less likely. Companies that are cloud agnostic can “diversify their portfolio” and become more resilient to failure and changes in the business IT landscape.
More customization: Using a strategy that’s cloud agnostic and multi-cloud lets you tweak and adjust your cloud roadmap exactly as you see fit. You don’t have to miss out on a feature that’s exclusive to a single provider just because you’re locked into a different solution.
Redundancy. Having systems in place across various clouds means you are covered should any one encounter problems.
The Cons of Being Cloud Agnostic
Greater complexity: Being cloud agnostic sounds great on paper, but the realities of implementation can be much more difficult. Creating a cloud strategy with portability built in from the ground up generally incurs additional complexity and cost.
“Lowest common denominator”: If you focus too much on being cloud agnostic, you may only be able to use services that are offered by all of the major public cloud providers. Even if AWS has a great new feature for your business, for example, you may be reluctant to use it unless you can guarantee that you can replicate it in Microsoft Azure or Google Cloud Platform. While more of a choice in enterprise strategy than a drawback, it is something to be aware of.
Strategies for Being Cloud Agnostic
A number of articles say that being truly cloud agnostic is a “myth.” These pieces argue that “cloud agnostic” is a state that’s not realistic or even desirable for most organizations.
In fact, being entirely cloud agnostic is an ideal that may or may not be achievable for you. Unless you are sure that the future won’t change, it may not be worth the effort to reach this goal. In large part, the tradeoff comes at the expense of your other IT and cloud objectives.
Nevertheless, there are a number of “low-hanging fruit” technologies that you can adopt on the path toward being cloud agnostic. These will be advantageous for your business no matter where you stand on the cloud agnostic spectrum.
For example, container technologies such as Docker and Kubernetes are an invaluable part of being cloud agnostic. Essentially, a “container” is a software unit that packages source code together with its libraries and dependencies. This allows the application to be quickly and easily ported from one computing environment to another.
Another tactic for being cloud agnostic is to use managed database services. These are public cloud offerings in which the provider installs, maintains, manages, and provides access to a database. The major public clouds such as AWS, Microsoft Azure, and Google all offer theoretical possibilities for migrating between providers.
That said, using products such as IronWorker that can deploy on any cloud, including fully on-premise deploys, is the easiest and most cost effective way to remain cloud agnostic. This is because with virtually one click, you can save your settings and deploy to whatever environment your enterprise wishes. In short, simplicity equals operational cost efficiency.
Technologies such as containers and managed database services will go far toward making your business more flexible and adaptable. This is true even if not completely cloud agnostic. If you do decide to become a cloud agnostic organization, consider using the services of Iron.io. Set up a consultation with us today to find out how our cloud agnostic IronFunctions platform can help your developers become more productive and efficient.
Google Cloud Run is a new cloud computing platform that’s hot off the presses from Google, first announced at the company’s Google Cloud Next conference in April 2019. Google Cloud Run has generated a lot of excitement (and a lot of questions) among tech journalists and users of the public cloud alike, even though it’s still in beta.
We will discuss the ins and outs of Google Cloud Run in this all-in-one guide, including why it appeals to many Google Cloud Platform customers, what are the features of Google Cloud Run, and a comparison of the Google Cloud Run alternatives.
Often just called “serverless,” serverless computing is a cloud computing paradigm that frees the user from the responsibility of purchasing or renting servers to run their applications on.
(Actually, the term “serverless” is a bit of a misnomer: The code still runs on a server, just not one that the user has to worry about.)
Cloud computing has soared in popularity over the past decade. This is thanks in large part to the increased convenience and lower maintenance requirements. Traditionally, however, users of cloud services have still needed to set up a server, scale its resources when necessary, and shut it down when you’re done. This has all changed with the arrival of serverless.
The phrase “serverless computing” is applied to two different types of cloud computing models:
BaaS (backend as a service) outsources the application backend to the cloud provider. The backend is the “behind the scenes” part of the software for purposes such as database management, user authentication, cloud storage, and push notifications for mobile apps.
FaaS (function as a service) still requires developers to write code for the backend. The difference is this code is only executed in response to certain events or requests. This enables you to decompose a monolithic server into a set of independent functionalities, making availability and scalability much easier.
You can think of FaaS serverless computing as like a water faucet in your home. When you want to take a bath or wash the dishes, you simply turn the handle to make it start flowing. The water is virtually infinite, and you stop when you have as much as you need, only paying for the resources that you’ve used.
Cloud computing without FaaS, by contrast, is like having a water well in your backyard. You need to take the time to dig the well and build the structure, and you only have a finite amount of water at your disposal. In the event that you run out, you’ll need to dig a deeper well (just like you need to scale the server that your application runs on).
Regardless of whether you use BaaS or FaaS, serverless offerings allow you to write code without having to worry about how to manage or scale the underlying infrastructure. For this reason, serverless has come into vogue recently. In a 2018 study, 46 percent of IT decision-makers reported that they use and evaluate serverless.
What are containers?
Now that we’ve defined serverless computing, we also need to define the concept of a container. (Feel free to skip to the next section if you’re very comfortable with your knowledge of containers.)
In the world of computing, a container is an application “package” that bundles up the software’s source code together with its settings and dependencies (libraries, frameworks, etc.). The “recipe” for building a container is known as the image. An image is a static file that is used to produce a container and execute the code within it.
One of the primary purposes of containers is to provide a familiar IT environment for the application to run in when the software is moved to a different system or virtual machine (VM).
Containers are part of a broader concept known as virtualization, which seeks to create a virtual resource (e.g., a server or desktop computer) that is completely separate from the underlying hardware.
Unlike servers or machine virtualizations, containers do not include the underlying operating system. This makes them more lightweight, portable, and easy to use.
When you say the word “container,” most enterprise IT staff will immediately think of one, or both, of Docker and Kubernetes. These are the two most popular container solutions.
Docker is a runtime environment that seeks to automate the deployment of containers.
Kubernetes is a “container orchestration system” for Docker and other container tools, which means that it manages concerns such as deployment, scaling, and networking for applications running in containers.
Like serverless, containers have dramatically risen in popularity among users of cloud computing in just the past few years. A 2018 survey found that 47 percent of IT leaders were planning to deploy containers in a production environment, while 12 percent already had. Containers enjoy numerous benefits: platform independence, speed of deployment, resource efficiency, and more.
Containers vs. serverless: A false dilemma
Given the massive success stories of containers and serverless computing, it’s hardly a surprise that Google would look to combine them. The two technologies were often seen as competing alternatives before the arrival of Google Cloud Run.
Both serverless and containers are intended to make the development process less complex. They do this by automating much of the busy work and overhead. But they go about it in different ways. Serverless computing makes it easier to iterate and release new application versions, while containers ensure that the application will run in a single standardized IT environment.
Yet nothing prevents cloud computing users from combining both of these concepts within a single application. For example, an application could use a hybrid architecture, where containers can pick up the slack if a certain function requires more memory than the serverless vendors has provisioned for it.
As another example, you could build a large, complex application that mainly has a container-based architecture, but that hands over responsibility for some backend tasks (like data transfers and backups) to serverless functions.
Rather than continuing to enforce this false dichotomy, Google realized that serverless and containers could complement one another, each compensating for the other one’s deficiencies. There’s no need for users to choose between the portability of containers and the scalability of serverless computing.
Enter Google Cloud Run…
What is Google Cloud Run?
In its own words, Google Cloud Run “brings serverless to containers.” Google Cloud Run is a fully managed platform that is capable of running Docker container images as a stateless HTTP service.
Each container can be invoked with an HTTP request. All the tasks of infrastructure management–provisioning, scaling up and down, configuration, and management–are cleared away from the user (as typically occurs with serverless computing).
Google Cloud Run is built on the Knative platform, which is an open API and runtime environment for building, deploying, and managing serverless workloads. Knative is based on Kubernetes, extending the platform in order to facilitate its use with serverless computing.
In the next section, we’ll have more technical details about the features and requirements of Google Cloud Run.
Google Cloud Run Features and Requirements
Google cites the selling points below as the most appealing features of Google Cloud Run:
Easy autoscaling: Depending on light or heavy traffic, Google Cloud Run can automatically scale your application up or down.
Fully managed: As a serverless offering, Google Cloud Run handles all the annoying and frustrating parts of managing your IT infrastructure.
Completely flexible: Whether you prefer to code in Python, PHP, Pascal, or Perl, Google Cloud Run is capable of working with any programming language and libraries (thanks to its use of containers).
Simple pricing: You pay only when your functions are running. The clock starts when the function is spun up, and ends immediately once it’s finished executing.
There are actually two options when using Google Cloud Run: a fully managed environment or a Google Kubernetes Engine (GKE) cluster. You can switch between the two choices easily, without having to reimplement your service.
In most cases, it’s best to stick with Google Cloud Run itself, and then move to Cloud Run on GKE if you need certain GKE-specific features, such as custom networking or GPUs. However, note that when you’re using Cloud Run on GKE, the autoscaling is limited by the capacity of your GKE cluster.
Google Cloud Run requirements
Google Cloud Run is still in beta (at the time of this writing). This means that things may change between now and the final version of the product. However, Google has already released a container runtime contract describing the behavior that your application must adhere to in order to use Google Cloud Run.
Some of the most noteworthy application requirements for Google Cloud Run are:
The container must be compiled for Linux 64-bit, but it can use any programming language or base image of your choice.
The container must listen for HTTP requests on the IP address 0.0.0.0, on the port defined by the PORT environment variable (almost always 8080).
The container instance must start an HTTP server within 4 minutes of receiving the HTTP request.
The container’s file system is an in-memory, writable file system. Any data written to the file system will not persist after the container has stopped.
With Google Cloud Run, the container only has access to CPU resources if it is processing a request. Outside of the scope of a request, the container will not have any CPU available.
In addition, the container must be stateless. This means that the container cannot rely on the state of a service between different HTTP requests, because it may be started and stopped at any time.
The resources allocated for each container instance in Google Cloud Run are as follows:
CPU: 1 vCPU (virtual CPU) for each container instance. However, the instance may run on multiple cores at the same time.
Google Cloud Run uses a “freemium” pricing model: free monthly quotas are available, but you’ll need to pay once you go over the limit. These types of plans frequently catch users off guard. They end up paying much more than expected. According to Forrester, a staggering 58% of companies surveyed said their costs exceeded their estimates.
The good news for Google Cloud Run users is that you’re charged only for the resources you use (rounded up to the nearest 0.1 second). This is typical of many public cloud offerings.
The free monthly quotas for Google Cloud Run are as follows:
CPU: The first 180,000 vCPU-seconds
Memory: The first 360,000 GB-seconds
Requests: The first 2 million requests
Networking: The first 1 GB egress traffic (platform-wide)
Once you bypass these limits, however, you’ll need to pay for your usage. The costs for the paid tier of Google Cloud Run are:
CPU: $0.000024 per vCPU-second
Memory: $0.0000025 per GB-second
Requests: $0.40 per 1 million requests
Networking: Free during the Google Cloud Run beta, with Google Compute Engine networking prices taking effect once the beta is over.
It’s worthwhile to note you are billed separately for each resource; for example, the fact that you’ve exceeded your memory quota does not mean that you need to pay for your CPU and networking usage as well.
In addition, these prices may not be definitive. Like the features of Google Cloud Run, prices for Google Cloud are subject to change once the platform leaves beta status.
Finally, Cloud Run on GKE uses a separate pricing model that will be announced before the service reaches general availability.
Google Cloud Run Review: Pros and Cons
Because it’s a brand new product product that’s still in beta, reputable Google Cloud Run reviews are still hard to find.
Reaction to Google’s announcement has been fairly positive, acknowledging the benefits of combining serverless computing with a container-based architecture. Some users believe that the reasonable prices will be enough for them to consider switching from similar services such as AWS Fargate.
Other users are more critical, however, especially given that Google Cloud Run is currently only in beta. Some are worried about making the switch, given Google’s track record of terminating services such as Google Reader, as well as their decision to alter prices for the Google Maps API, which effectively shut down many websites that could not afford the higher fees.
Given that Google Cloud Run is in beta, the jury is still out on how well it will perform in practice. Google does not provide any uptime guarantees for cloud offerings before they reach general availability.
The disadvantages of Google Cloud Run will likely overlap with the disadvantages of Google Cloud Platform as a whole. These include the lack of regions when compared with competitors such as Amazon and Microsoft. In addition, as a later entrant to the public cloud market, Google can sometimes feel “rough around the edges,” and new features and improvements can take their time to be released.
Google Cloud Run Alternatives
Since this is a comprehensive review of Google Cloud Run, we would be remiss if we didn’t mention some of the available alternatives to the Google Cloud Run service.
In fact, Google Cloud Run shares some of its core infrastructure with two of Google’s other serverless offerings: Google Cloud Functions and Google App Engine.
Google Cloud Functions is an “event-driven, serverless compute platform” that uses the FaaS model. Functions are triggered to execute by a specified external event from your cloud infrastructure and services. As with other serverless computing solutions, Google Cloud Functions removes the need to provision servers or scale resources up and down.
Google App Engine enables developers to “build highly scalable applications on a fully managed serverless platform.” The service provides access to Google’s hosting and tier 1 internet service. However, one limitation of Google App Engine is that the code must be written in Java or Python, as well as use Google’s NoSQL database BigTable.
Looking beyond the Google ecosystem, there are other strong options for developers who want to leverage both serverless and containers in their applications.
The most tested Cloud Run alternative: Iron.io
Iron.io is a serverless platform that offers a multi-cloud, Docker-based job processing service. As one of the early adopters of containers, we have been a major proponent of the benefits of both technologies.
The centerpiece of Iron.io’s products, IronWorkeris a scalable task queue platform for running containers at scale. IronWorker has a variety of deployment options. Anything from using shared infrastructure to running the platform on your in-house IT environment is possible. Jobs can be scheduled to run at a certain date or time, or processed on-demand in response to certain events.
In addition to IronWorker, we also provide IronFunctions, an open-source serverless microservices platform that uses the FaaS model. IronFunctions is a cloud agnostic offering that can work with any public, private, or hybrid cloud environment, unlike services such as AWS Lambda. Indeed, Iron.io allows AWS Lambda users to easily export their functions into IronFunctions. This helps to avoid the issue of vendor lock-in. IronFunctions uses Docker containers as the basic unit of work. That means that you can work with any programming language or library that fits your needs.
Google Cloud Run represents a major development for many customers of Google Cloud Platform who want to use both serverless and container technologies in their applications. However, Google Cloud Run is only the latest entrant into this space, and may not necessarily be the best choice for your company’s needs and objectives.
If you want to determine which serverless + container solution is right for you, speak with a skilled, knowledgeable technology partner like Iron.io who can understand your individual situation. Whether it’s our own IronWorker solution, Google Cloud Run, or something else entirely, we’ll help you get started on the right path for your business.
Iron was one of the pioneers of Serverless, so we’re excited to announce that we’ll also be one of the first companies to offer the next generation of compute: It’s called Computerless™.
Unlike Serverless, this technology removes the physical machine completely. Our offering piggy-backs off the recent developments in fiber optic technology developed at the University of Oxford. If you haven’t heard about this breakthrough, we’ll do our best to explain:
Researchers have found a way to control how light travels at the molecular level, thus being in complete control of the resulting attenuation. Molecular gates can then be created, and state stored in finite wavelengths. It’s somewhat equivalent to qubits in quantum computing, but in the case of optical fiber, it’s a physical reality.
The end result of this technological release allows for computers to be fully encapsulated in fiber optic cable. The usual components needed are now mapped 1-to-1, via light. This has allowed Iron’s infrastructure to completely change. While we’ve run our infrastructure on public clouds like AWS and GCP in the past, we’ve been able to leave that all behind. We’re now able to push our entire suite of products into optical cable itself:
In the next few months, we’ll be pushing all of our customer’s sensitive data into the cables shown above as well as running all Worker jobs through them. We’re pretty sure the cables we purchased are for multi-tenant applications, so you can probably rest assured that we’re doing the right thing. In fact, NASA has already expressed an interest in licensing this technology from Iron. Other interested parties include the government of French Guiana and defense conglomerate Stark Industries.
Researchers have kind-of concluded that this technology is ready for prime time, and also are quick to state the fact that in 1998, The Undertaker threw Mankind off Hell In A Cell, and plummeted 16 ft through an announcer’s table.
Guy Podjarny published a great blog post discussing the Serverless space from a security perspective. I highly recommend reading it as it touches on some great points, going over both the security benefits and possible risks.
Two points he made definitely stood out to me, and the first was the concept of a greater attack surface. When I explain FaaS (Functions as a Service) to people, many immediately equate a function as being synonymous to a simple API endpoint. To a degree, they are correct. Then, what’s the difference, and why should we look at security in regard to both from different perspectives? I believe the differentiator becomes how the endpoint is exposed, and what its purpose is.
Standard API endpoints will often belong to a broader application or set of microservices that reside behind a shared layer of security. This could be dedicated network hardware, hardened reverse proxies, etc. As a security minded developer, you develop your endpoint and consider the possible client side attack vectors (Guy points to the OWASP Top Ten guide (Open Web Application Security Project) which is a great place to start; Thomas Ptacek also has a great list here); then possibly move on to write another endpoint, which will share these concerns, all the time relying on that first level layer of security.
When you start developing a suite of functions, things can start to get fragmented. Dependencies start to change between functions, software versions might differ, and the ways the functions are triggered may require different configurations on the network/gateway layer.
The second point that stood out was around monitoring: There are countless battle-tested monitoring solutions out there, but the way functions are deployed and used within an underlying architecture might leave them completely out of their scope. Guy makes a great point about how many of these products are agents that rely on long running processes to keep an eye on and collect from. In order to monitor functions, different techniques need to be implemented for short-lived and hot processes.
All of these are great problems to have and point to fast moving innovation in already fast moving industries. You’ll see most vendors and platforms already tackling these issues and building solutions into their products. This space is still young! Here at Iron, we’re committed to helping make IronFunctions become a respected open source solution for delivering FaaS to wherever you want to deploy it.
We are pleased to announce a new project to enable Functions as a Service (FaaS) on OpenStack — Picasso.
The mission is to provide an API for running FaaS on OpenStack, abstracting away the infrastructure layer while enabling simplicity, efficiency, and scalability for both developers and operators.
Picasso can be used to trigger functions from OpenStack services, such as Telemetry (via HTTP callback) or Swift notifications. This means no long running applications, as functions are only executed when called.
Picasso is comprised of two main components:
The Picasso API server uses Keystone authentication and authorization through its middleware.
Picasso leverages the backend container engine provided by IronFunctions, an open-source Serverless/FaaS platform based on Docker.
Today we’re excited to announce IronFunctions, our first major open source project.
IronFunctions is a serverless microservices platform that you can run anywhere; on public, private, and hybrid clouds, even on your own laptop. The world is moving towards hybrid/multi-cloud, so should your serverless platform.
Functions are packaged using Docker so it supports any language, any dependencies, and can run anywhere. It will also eventually support other container technologies, and today it supports the Lambda function format for easy portability and will soon support others as well.
IronFunctions is written in Go, extremely fast, and written with scalability and operability in mind.
Finally, it’s being driven by our team at Iron.io that is unashamedly taking credit for coining the term serverless dating back to 2011 and 2012. We’ve launched billions of containers through our flagship serverless job processing service IronWorker, and now bring this knowledge and experience to IronFunctions to round out our portfolio of products with synchronous capabilities.
So without further ado, we’d love your help in building an amazing platform and community. Fork the repo and please give us pull requests and create issues!
In February, we launch a beta called Project Kratos. It promised to bring Lambda-like functionality to any cloud – public, private, hybrid or on-premises. As we quickly approach Q4, February seems like a long time ago, but so much has happened since then.
Over the past seven months, serverless computing has gained momentum as more than just the hot topic of the moment. Because it allows enterprises to build and deploy applications and services at scale on flexible platforms that abstract away physical infrastructure, it’s quickly becoming a must have for the modern enterprise. It will soon be a competitive advantage for those already implementing it.
Our journey with serverless has also moved from a project announcement full of promises to the solution that is widely available today. First, in April, we announced the general availability of its multicloud solution. Since then, we’ve systematically partnered with leading cloud providers to support multicloud development.
In April, Iron.io announced its partnership with Mirantis to bring event-driven, serverless functionality to the OpenStack community. The joint solution enables enterprise developers using OpenStack to deliver applications and services faster through the serverless experience provided by Iron.io.
In June, Iron.io brought the serverless experience to Red Hat OpenShift — a pairing that provided users with an end-to-end environment for building and deploying applications at scale, without the headaches of complex operations.
And in August, Iron.io announced its strategic partnership with Mesosphere, enabling microservices and serverless computing for modern data centers. Joint customers using Mesosphere’s Data Center Operating System (DC/OS) with Iron.io could experience enhanced flexibility to develop their hybrid cloud strategy and run distributed job processing across heterogeneous environments.
Yesterday, we added an announcement that serverless functionality is now available on Cloud Foundry and Iron.io supports Diego as a runtime for Iron.io workloads. Iron.io is now able to be deployed on top of Cloud Foundry, run inside of Cloud Foundry, and scale out Cloud Foundry containers.
Wow. I was here for all of it and it still seems like a lot, but it’s only the beginning. The Iron.io team is committed to bringing a serverless experiences to developers and companies far and wide.
This week, the Cloud Foundry Summit is happening in Frankfurt. If you are there, give us a shout. The Iron.io team is there and would love to meet with you. It looks to be a great conference.
We at Iron.io have been fortunate to have been a member of the Cloud Foundry Foundation for several years. It’s focus on high scalability, auto-scaling, and multicloud support matches what Iron.io delivers to its customers.
Today, Cloud Foundry and Iron.io took this commitment to a new level with the announcement that we are working together to bring a true multicloud serverless experience to the thousands of enterprises using Cloud Foundry. Companies can now offer their developers serverless functionality. That means developers can run code without provisioning or managing servers across multiple clouds. This is a key requirement for enterprises that maintain specific data types in an on-premises or private cloud environment.
Iron.io also announced its support for Diego as a runtime for Iron.io workloads; Iron.io is now able to be deployed on top of Cloud Foundry, run inside of Cloud Foundry, and scale out Cloud Foundry containers.
If you want to schedule a meeting at this week’s Cloud Foundry Summit in Frankfurt, or schedule a chat with those of us holding down the fort in the office, fill out this Contact Us form and we’ll get a meeting/call set up.
There has been a lot of buzz around the Serverless trend lately; what it really means and what are its merits. At the end of the day it’s really just a new way to treat certain workloads – background jobs. How does this new pattern fit in the context of developing cloud native applications and operating container platforms such as Red Hat OpenShift?
LAYING THE FOUNDATION
Delivering continuous innovation to customers often leads to continuous pressure on the developers to build and ship software… well, continuously. Smart companies are doing all they can to empower their development teams with the right culture to encourage productivity, and the right tools to make it happen. Emerging as the foundational layer for many organizations’ application development efforts is a container application platform, with OpenShift as a leading choice.
As infrastructure resources continue to be commoditized, and as services continue to be exposed as APIs, having a foundational layer is critical to bring everything together. This is especially important when dealing with multiple distributed applications and multiple distributed teams, as containerized applications, workloads, and services need a unifying environment. Continue reading “OpenShift Ecosystem: Iron.io Brings a Serverless Experience to OpenShift”