Companies are now collecting and analyzing more information than ever before and using more and more applications to do it. According to an estimate by Skyhigh Networks, the average enterprise today uses 464 custom-built applications for their internal business processes.
In particular, many of these applications require real-time updates and data in order to function at maximum effectiveness. However, getting this real-time information to the right places at the right times is a thorny problem for developers.
Different applications may be written in different programming languages, run on different operating systems, or use different data formats—and that’s just the software itself. What’s more, sending data over enterprise networks can be slow and unreliable.
The good news is that these issues can be solved with an enterprise-grade messaging system. An enterprise messaging system (EMS), or just “messaging system” for short, is a solution that allows different software applications without built-in integrations to connect with each other, exchange information, and scale on an as-needed basis.
Messaging systems facilitate the sending and receiving of information between processes, applications, and servers via asynchronous communication. Each message is translated into data packets and then sent to a message queue, where it can be processed by the receiver at its own pace.
Which Messaging System is Best for You?
The benefits of messaging systems are enormous, including the convenience of asynchronous communication and the simplicity of integrating disparate software applications. The question then becomes: which messaging system is right for my organization?
In this article, we’ll help you figure out the best messaging system by comparing and contrasting two of the best-in-class solutions: Apache Kafka and Iron.io’s IronMQ. We’ll go over everything you need to know about these two options: their features and benefits, their pros and cons, and ultimately how they stack up against each other.
What is Kafka?
Apache Kafka is an open-source software platform for stream processing that can be used as a message queue. The project was first developed by LinkedIn, and was made publicly available through the open-source Apache Software Foundation in 2011.
Like many messaging systems, Kafka uses the “publish-subscribe” messaging pattern. Rather than the message sender designating specific recipients, the sender classifies the message into one or more topics. The message is then sent to all recipients who have subscribed to receive messages from these topics.
Kafka can be configured to work with a variety of popular programming languages, including Python, Ruby, Java, Scala, and C/C++. Kafka is also used as a log management solution to collect log files from different servers and store them in a centralized location. Uber, Spotify, Slack, and Coursera are just a few of the major tech companies that use Kafka as part of their tech stack.
What is IronMQ?
IronMQ is a cloud-based messaging queue solution that links together the services and components of a distributed system. Unlike other messaging systems, IronMQ has been built specifically for the cloud, although it’s compatible with on-premises deployments as well.
The IronMQ platform handles much of the “heavy lifting” that enterprises need to do when setting up a messaging system. Issues such as work dispatch, load buffering, synchronicity, and database offloading are all handled behind the scenes, and end-users are freed of any installation or maintenance obligations.
Major companies like CNN, Twitter, Philips, and Coinbase all rely on IronMQ to exchange critical real-time information between the processes, applications, and servers running in their enterprise IT environments. Client libraries are available in a wide variety of programming languages, including Python, Ruby, Java, PHP, and .NET.
Apache Kafka: Features and Benefits
In this section, we’ll delve more deeply into the features and benefits of Apache Kafka.
Open-source: As an open-source software project, Apache Kafka is totally free of charge for enterprises and developers alike. Some cloud providers such as Amazon Web Services have announced a “managed Kafka service” that will handle some of the technical complexities of Kafka for a price.
Part of the Apache ecosystem: Kafka plays nicely with other offerings from Apache, including stream processing frameworks such as Apache Apex, Apache Flink, and Apache Storm.
High performance: A number of performance optimizations enable Kafka to outperform alternative messaging queue solutions. For example, Kafka does not store indexes tracking the number of messages it has, which reduces the system’s overhead. Kafka is especially well-tuned for smaller messages around 1 kilobyte in size.
Scalability and fault-tolerance: Topics in Kafka can be parallelized into different partitions, which are always highly available and replicated. This allows Kafka to recover stream data even after an application failure. Kafka is also scalable for both concurrent writing and reading of messages.
Well-suited for big data: Thanks to its optimized performance and scalability, Kafka is a strong fit for projects that need to relocate massive quantities of data quickly and efficiently. For example, Netflix uses Kafka to process data regarding performance events and diagnostic events, enabling it to handle 8 million events per second.
IronMQ: Features and Benefits
We’ve gone over the benefits and features of Apache Kafka, so how does IronMQ compare?
Better than self-managed messaging queues: As a cloud-based platform, IronMQ offers many benefits over a self-managed solution, including lower complexity, faster time to market, and better reliability. Setup is drastically simpler for distributed systems since you don’t have to worry about the intricacies of installing a messaging system on multiple servers.
Highly available and scalable: Thanks to its cloud origins, IronMQ uses multiple high-availability data centers, ensuring that performance issues are few and far between. Automated failover means that IronMQ message queues can use backup availability zones in the event of an outage. The IronMQ platform can also automatically scale and handle instances of increased demand, without you having to distribute resources yourself.
Feature-rich: IronMQ includes a large set of advanced message queue features to suit every user’s needs: push and pull queues, long polling, error queues, alerts and triggers, and more. Push queues inform receivers when a new message is available, pull queues ask a client for new messages at regular intervals, and long polling keeps a persistent connection open in order to allow responses at a later time.
Multiple deployment options: IronMQ is available not only in the public cloud, but also on-premises and hybrid cloud setups—whatever best fits your current environment.
Apache Kafka vs. IronMQ: Comparison and Reviews
Given their feature set and popularity, it’s no surprise that both Kafka and IronMQ have received high marks from the overwhelming majority of their users. In this section, we’ll discuss reviews for Apache Kafka and IronMQ to help you distinguish between the two solutions.
Apache Kafka Reviews
Kafka has an average rating of 4.3 out of 5 stars on the business software review website G2 Crowd, based on 34 evaluations. According to one user, Kafka is “easy to use, brings great value to the architecture, and enables scalability and extensibility.”
Another reviewer enthuses that Kafka offers a “super fast and near real-time queue mechanism. Debugging is simpler. Its persistence queue provides the great feature of retention of events for n number of days. This is really helpful to avoid data loss in case of some issue or unexpected situation.”
While many users praise the initial simplicity of Kafka integrations, however, the learning curve afterward may be steep. This is particularly true for open-source solutions such as Kafka, which may have little in the way of support unless using a cloud-managed service. One reviewer warns that Kafka’s user-friendliness leaves much to be desired, especially for smaller companies without the IT know-how of bigger enterprises:
“For the various errors I ran into in trying to get automatically launched per-test test clusters working, Googling and Stack Overflow answers tended to be contradictory… That tells me I need someone (most likely me) to become a Kafka guru. That’s not an expense a small startup should incur, and choosing to use a technology that requires that kind of babysitting is not one you make lightly.”
Meanwhile, IronMQ enjoys an average rating of 4.5 out of 5 stars on the business software review website Capterra, based on 26 reviews. One user in the hospitality industry notes that IronMQ “let us quickly get to solving the problems that really mattered for our company,” calling the platform “simple to implement in our system… reliable, fast, and easy to use.”
In contrast with Kafka, reviewers agree that IronMQ is capable of meeting the needs of small businesses as well as large enterprises. According to a Capterra review from startup CEO Ryan M.:
“We process millions of jobs a month and needed a way to scale outside of running our own Sidekiq instance. IronWorker and IronMQ were the team that solved it for us. We run a pretty lean startup and need to offload as much development operations as possible… We discovered IronMQ to be the right balance of functionality, ease of use, and cost.”
Both Apache Kafka and IronMQ are excellent options for enterprises who need a reliable, scalable messaging queue solution. However, different organizations will likely find a reason to prefer one alternative over the other.
In particular, organizations that can’t or don’t want to handle all the technical complexity, or who require a wide range of features and flexibility, are likely better off with IronMQ. While Apache Kafka is a powerful solution for stream processing, it will require a good deal of knowledge and work behind the scenes to get up and running, unless you opt for a managed Kafka service.
Want to learn more about how IronMQ can help your organization build a highly available, reliable, scalable messaging queue? Get in touch with our team today to start your free trial of IronMQ.
Data breaches are getting more common these days with increased globalization and the accessible networks of the internet. This has led to identity thefts, stolen PIN codes, compromised security systems. Thankfully, with the advent of 2FA, some banks and retail companies are heightening the security defenses of their clients and customers.
As a rule of thumb, a 2FA should be included to any application that deals with sensitive credentials and passwords. However, not many may truly understand the technology behind 2FA verification, in fact, some may find the process troublesome and unnecessary. But as we will show you, this is far from the truth.
Increasing Cyber Threats
According to some statistical reports, cyber threats have been steadily on the rise around the world. This may be due to the development of advanced malware and phishing software that continues to affect thousands of users. It is also worrying that some third-party application stores carry ostensible fronts while harboring malware in their content.
Based on a 2018 Harris Poll survey, a whopping 80 million Americans have reported experiences of identity theft of some form. This is a staggering number. Such worrying trends may continue rising as younger generations of people are known to spend more time on social networks and e-services, which make them vulnerable to cyber exploitation.
Giant companies such as Target and Facebook have been recently caught in a series of open investigations linked to compromised security. If it can happen to them, it can happen to anyone. Bad press can really harm customer relations. So, when it boils down to client security, prevention is definitely better than cure.
The Rise of 2FA
2FA, or otherwise known as two-factor authentication refers to a security feature that reinforces a standard one-time password. The multifactor authentication method provides an additional buffer against malicious individuals from hacking into an account or siphoning details.
Traditionally, one-time passwords sufficed but these days, the triviality of some passwords have proven detrimental to the security of the individual. Some commonly hacked passwords include birth dates, the name of loved ones (including pets), “password” and pet names.
As an additional measure against these loopholes, many big names such as Google and PayPal have integrated 2FA into their applications and websites as a means of fostering customer trust and confidence in the security of their services.
The Idea Behind 2FA
The fundamental concept of 2FA is comparable to the functionalities of a debit card. A thief may steal the debit card from you, but they require your bank account password in order to withdraw the money from your bank account. Simply owning the card or the password does not gain access.
2FAs prevent hackers from accessing your account even if they have successfully entered your one-time password.
There are several ways that 2FAs work. Some applications may choose to link an account to your mobile number or email address, where you will receive a one-time notification number to be keyed in. However, this may be ill-advised as advanced hackers may be able to gain access to your devices and accounts through means of social engineering such as copying your SIM card. A better alternative might be found in specialized 2FA mobile applications that generate randomized tokens, which changes the digits each time you log in.
Why Apply 2FA Phone Verifications?
Essentially, 2FA adds an extra layer of protection to shield your personal information against unauthorized individuals. As society advances in cyber technology, so comes the rise of more tech-savvy cyber criminals, who will utilize innovative methods that can easily hack into one-time passwords.
Additionally, 2FA phone verification processes may be the most convenient method since most people carry their phones most of the time. However, as mentioned, a mobile token generator is a better alternative to a direct mobile 2FA authentication, which may be easily hijacked by malicious individuals.
Although when it comes down to security, there is always the risk of a hack, 2FA certainly significantly reduces occurrences. Consider the analogy of a poorly fenced up home versus a high-security mansion. Criminals will be less likely to target your accounts and profiles if 2FA gives them the additional burden of cracking a second code.
Seeking Professional Services
It can be tedious for companies and enterprises to sieve out the best solutions to their mobile security needs. Thus, it may be important to seek support from an expert you can trust to make the right recommendations.
IronAuth is dedicated in offering expert developer tools in tackling the biggest concerns that your company faces. We track the latest trends in providing you the latest information on the rapidly changing industry to deliver the winning answer to your needs.
Visit us here for more information on how we can help optimize your mobile security systems to give your customers a peace of mind.
The term “DevOps” is a phrase that was coined by Patrick Debois approximately ten years ago. It’s now an accepted term by software, and IT teams across the globe. They use it for describing the methodology behind operation and development engineers working together from design to development. What does this definition mean for the future of DevOps? Let’s take a look.
Developing a strong understanding of DevOps allows you to experience improvements regarding the efficiency and quality of the development of your mobile application. In the coming years we can expect to see some significant changes. It’s possible to stay ahead of the competition while simultaneously improving the efficiency of your internal operations if you have an understanding of what’s ahead.
Mark Debney from 6poin6 writes, “Whilst DevOps culture will be integrated into development teams. For those of us with DevOps in our job title, I see the role evolving into a cloud specialty with a focus on optimising the usage of cloud technologies, working as specialist centralised development teams creating tools to augment and aid the development process, providing guidance and best practice across an organisation’s rapidly changing cloud estate.”
What is DevOps?
Before looking at the future of DevOps, let’s take a look at its definition. Essentially, DevOps is a fusion of terms–software development and information technology operations. It’s possible to gain oversight over your business’s entire pipeline when incorporating DevOps into the way you’re running operations. In doing so, you’re allowing your teams to work more efficiently with fewer redundancies.
There was a growing divide between the product’s creation and its support before the world of DevOps. Ultimately, this led to production issues as a result of these silos. However, Agile methodology got customers, developers, managers, and QA working together. Even though they were iterating toward a better product, operations, and infrastructure wasn’t addressed. The product’s delivery and infrastructure can be seen as an extension of Agile when looking at DevOps.
What is the CALMS model?
The CAMS model is essentially the framework for DevOps, and it was created by Damon Edwards and John Willis, authors of the DevOps Cafe podcast, in 2010. CAMS is an acronym for Culture, Automation, Measurement, and Sharing. Later, Jez Humble added the “L,” which stands for “Lean” to the acronym, and now it’s “CALM.”
Culture: focuses on people and embraces change and experimentation.
Automation: is continuous delivery with infrastructure as code.
Lean: focuses on producing value for the end-user utilizing small batches.
Measurement: measures everything while simultaneously showing the improvements.
Sharing: open information sharing using collaboration and communication.
Daniel Greene of TechCrunch writes, “You can visualize DevOps as a conveyor belt, where many checks and balances are in place, at all stages, to ensure any bundle coming down the belt is removed if it’s not good enough, and delivered to the end of the belt (e.g. production) safely and reliably if it is.”
One of the critically new standards regarding development is cloud computing. That means, now more than ever, it’s vital to have a DevOps pipeline in place. The main reason is to keep a separation between development and deployment. DevOps is going to gain more prominence as it acts as liaisons between those two arms of your development cycle. However, the software is going to begin depending more on multiple clouds. In turn, DevOps professionals will find their jobs more challenging.
As DevOps grows to meet the needs of keeping up with multi-cloud environments, it will become more about responding to those changing technologies. These professionals will also be responding to the power of these platforms and making adaptations to ensure their software is getting the most benefits out of them. DevOps will also have to possess an understanding of the cloud platform’s native features and communicate them to their teams. That way, they can minimize the amount of work occurring throughout the deployment.
What Does This Mean for the Future of DevOps?
The future of DevOps means a lot of containerization of software, which ultimately means applications will run using the cloud. Many of these software applications will be replacing some of the traditional functions of DevOps. As a result, the world of DevOps will experience a dramatic shift. The main reason is that there need to be clear boundaries defined between operations and development.
Because the industry will continue making shifts toward software management using standardized frameworks, DevOps professionals will have more time to drive efficient innovations. These professionals will also have more time to tackle the challenges they face regarding managing large clusters of complex applications across technology stacks.
Tom Smith from DZone asked IT executives about the future of DevOps, and received this as one response, “The biggest opportunity for DevOps is to drive into tech stacks and organizations that think that a move to DevOps requires a complete re-architecture of their application or adoption of replacement technologies. While those sorts of changes may be excellent opportunities to introduce culture change as well, teams running existing business-critical apps in “monolithic” architectures can take advantage of DevOps as well, if they choose the right tools.”
What Are the Trends Regarding DevOps?
Growing trends are also occurring in the world of cloud computing and it’s relationship to DevOps:
There’s an increase in diversity of cloud services which are leading to multi-could and hybrid infrastructures.
Data managers are facing more requirements regarding the emergence of DataOps.
Kit Merker writes, “The emerging methods of DataOps draw directly from the key principles of DevOps — automation to help distributed teams support frequent and continuous integration and delivery. In the same way that DevOps helps developers, quality assurance, and operations to smoothly and securely collaborate, DataOps provides the same benefits to the joint efforts of developers, data scientists, data engineers, and operations.”
When more than one cloud management platform is utilized in a single IT environment, it’s a multi-could accommodation. This occurs for several reasons, including:
to minimize downtime through redundancy
reduce data loss and sprawl
avoid vendor lock-in
provide versatility to meet a team’s varying project needs
As a result, DevOps teams must work toward meeting multi-cloud needs by becoming more scalable and Agile. It’s possible to achieve this goal utilizing continuous release and integration, as well as automation.
There may be problems with DevOps attempting to keep up by continuing to do the same thing, but quicker. The main reason is traditional DevOps apps are monolithic. Therefore, cloud-based applications are wiser to use. That way, they’re easier to scale, automate, and move.
More Focus on Automation
DevOps is becoming an industry standard for many businesses. According to a report issued by Capgemini, 60% of businesses either adopted DevOps or planned to do so during 2018. Statistics like this one demonstrates that DevOps is a necessary part of your business plan if you expect to respond quickly to the demands of the market, improve your business’s time-to-market, and keep your software solutions updated regularly.
Many businesses wonder if automation can be continuous, on-demand, always optimal, and contextual. Do you know the six “C’s” of the DevOps cycle? Understanding this cycle will help you apply them better between the different stages of automation. Here they are:
Continuous Business Planning
Sustained Release and Deployment
Collaborative Customer Feedback & Optimization
Smart implementation of automation means continuous updates of the DevOps structure can occur as developers deliver content to users despite changes. However, it also means a DevOp’s work is on-going. Automation is going to continue taking hold in the future of DevOps. The problem is many organizations are automating too much. As a result, communications are breaking down among teams.
As the industry continues to grow, more DevOps automation tools are going to roll out. That’s where developers will need skills to know which ones possess features that can be automated and which require an engineer. Otherwise, businesses will find themselves implementing what is new and causing problems with automation instead of making it work to their benefit.
These needs will eventually be met by AIOps, which stands for artificial intelligence for IT operations. Organizations must understand that automation has reached a point of inflection regarding adoption and implementation. Because of this it’s not yet subsumed by AIOps. As a result, it makes sense to carefully examine how automation should be utilized to meet demands better.
Torsten Volk, managing research director for containers, DevOps, machine learning, and AI at Enterprise Management Associates, states, “The future of DevOps requires what I like to call ‘continuous everything.’ This means that security, compliance, performance, usability, cost, and all other critical software components are automatically and continuously implemented without slowing down the release process. In short, the optimal DevOps process is fully automated and directly synchronized with rapidly changing corporate requirements.”
Code Will Become a Required Skill
Statistics indicate that, as of 2018, 86% of businesses have either implemented DevOps or plan to do so. As a result, this means organizations must invest in their DevOps engineers. However, due to the quick pace, technologies are changing, it’s challenging for individuals and businesses to keep up with their DevOps skills.
The following three categories will help DevOps professionals gain a sturdy grip on cultivating their expertise:
Ability: This is the level at which a DevOps professional can perform their tasks. Ability is natural, as opposed to skills and knowledge which are learned. Often, many DevOps professionals currently working in the field possess natural abilities.
Knowledge: This is something that’s learned. For example, a DevOps professional is born with the knowledge of the inner-workings of Jenkins. Therefore, they must obtain knowledge of it using instruction and personal study. It’s critical for DevOps professionals to continuously learn, review, and understand the latest information regarding DevOps best practices, systems, and technologies.
Skill: This is something that is learned through experience or training. Ultimately, DevOps professionals are applying what knowledge they’ve obtained to situations they’re experiencing in real-life. These skills can only be further improved by a DevOps professional with practice.
Learning Code: The Critical Need
One of the most significant demands in DevOps is testers who know how to code and automate scripts. They do this to test various cases. If you’re not sure how these skills, the recommendation is that you learn how to code immediately. You’ll find that, when you understand the various tools for DevOps and how to automate scripts, these skills play a critical role in today’s software development.
The expectation is that, if testers don’t learn code within their automated scripts, they’ll perish. Manual testing is time-consuming, and the expectation is that it will become obsolete before 2020. Automation not only ensures the market receives features faster, but it also increases the efficiency in testing.
According to Andrae Raymond, programmer and software consultant at Software Stewards, “When proper tests are in place, you can rest assured that each function is doing what it was written to do. From all stages from development to deployment we can run tests to make sure the entire system is intact with new features.”
Coding Creates Security Barriers
DevOps engineers can also write and deploy secure code quickly. In doing so, they’re protecting businesses from unwanted attacks. They’re also ensuring applications and systems have a defense mechanism in place to protect against the most common cybersecurity vulnerabilities.
Engineers will find that coding is an on-going process that undergoes many changes and updates. Therefore, a DevOps engineer must have flexibility. What that means is they’re continuously integrating and developing new operations and systems into code. While doing this, they’ll be utilizing flexible working skills and adapting to the code’s changes.
It’s also vital that engineers are comfortable with moving from various areas of a software construction to another. No matter if it’s deployment, integration, testing, or releasing–they must be able to move seamlessly.
Because code is continuously changing, engineers are also required to make on-the-spot decisions. They’ll be fixing incoherent code elements and, as a result, quick decisions are required. These coding changes must occur rapidly to ensure development and deployment can occur. It’s this kind of confidence that makes a successful coding engineer.
Security Implementation Will be a Driver
Security plays a significant role in the world of DevOps. The more automation occurs, the more problems can arise. That means, the more connected we become, the more exposure we also create.
What are the Benefits of Security Implementation?
Improvements in the effectiveness and efficiency of operations.
Teams across the company experience healthier and stronger collaborations.
Security teams experience stronger agility.
Quality assurance and automated builds have a more conducive environment.
Easier to identify vulnerabilities for applications and systems.
More freedom to focus on high-value projects.
The cloud experiences improved scalability.
An increase in the company’s ROI.
Make Security a Priority
Because DevOps practices are driven by (CI/CD) integrations and deployments that occur continuously, big releases are replaced by faster, agile release cycles. It’s possible to address your customer’s needs and demands daily by using the CI/CD pipeline to employ rapid changes. Because it’s possible to automate the CI/CD pipeline, security must be a priority. Therefore, it cannot be thought of as an add-on feature. Instead, it must be included in the software’s design.
Anthony Israel-Davis writes, “As with prevention, DevOps is uniquely positioned to take advantage of detective controls. In traditional IT environments, detection tends to be a runtime concern, with DevOps, detection, correction, and prevention can be wrapped into the pipeline itself before anything hits the production environment.”
Even though DevOps and security have always worked in conjunction with each other, you must ensure your developers are using the same software packages, dependencies, and environments throughout the software development process. The expectation is that, as DevOps continues growing in the world of IT and being adapted globally, more focus will be placed on it in the fields of cloud computing, IoT, and security.
Expect Some Challenges
Despite solving many challenges throughout the software development process, DevOps security does introduce new ones. According to a survey conducted by SANS, fewer than 46% of IT security professionals are “confronting security risks upfront in requirements and service design in 2018–and only half of respondents are fixing major vulnerabilities.”
As a result, environments end up with an uncoordinated, reactive approach to incident mitigation and management. Under many circumstances, this lack of coordination isn’t apparent until incidents occur, and a system attack or break occurs.
Security breaches can reap havoc on systems that have long-term effects. One example of a massive breach is Uber’s in late 2016. Two hackers broke into the company’s network, stealing personal data, including names, email addresses, and phone numbers of 57 million Uber users. During this breach, the hackers also stole the driver’s license numbers of 600,000 Uber drivers. According to Bloomberg, they used Uber’s GitHub account, which is where Uber’s engineers track projects and store code, to obtain the username and password. Then, they were able to access Uber’s data that was stored in one of Amazon’s servers.
Security is Everyone’s Responsibility
Jayne Groll, co-founder, and CEO of the DevOps Institute states, “DevSecOps basically says security is everybody’s responsibility with security as code. We need to start testing security much earlier in the cycle rather than making it a downstream activity. I think the security community is starting to embrace that from a tools perspective and for their personal future. I think two years from now we are going to see security as code being the norm.”
The problem with this security breach is Uber paid off the hackers to keep them quiet. However, it wasn’t long until the data breach was eventually discovered. At that point, it became a nightmare regarding public relations. Dara Khosrowshahi, Uber’s C.E.O. at the time of the hack, indicated in a statement, “While I can’t erase the past, I can commit on behalf of every Uber employee that we will learn from our mistakes.” Khosrowshahi remains on Uber’s board of directors.
When a DevOps environment is running securely, it’s operating on different policies, processes, and tools to facilitate secure and rapid releases. Use the Uber example, there needed to be a final scan to ensure there were no credentials left embedded anywhere in the code. When these pieces come together, they provide a bulletproof security system throughout the development, release, and management phases of the application.
That’s where DevSecOps comes into play. DevSecOps is a combination of both security and privacy. It’s where security is implemented into the design lifecycle of software development. In doing so, there are fewer vulnerabilities. These security features also help bring security features closer to meeting business objectives and IT standards. Use of these models helps ensure everyone is responsible for security.
Protection Against New Risks
DevSecOps offers protections against the new types of risks found when introducing CI/CD within the testing framework of DevOps. Security checks are now integrated into the process while building the code. DevSecOps covers the analysis of code, automated security controls, and post-deployment monitoring. Because DevOps professionals remain engaged throughout the process, they’ll find and mitigate issues before launching.
As a result, the development process is a more cohesive experience, as well as an improved user experience. Thanks to the improvements in the delivery chain, users receive feature updates quicker, more secure software, and they no longer have to deal with technology that lags.
Microservice Architecture Will Increase in Demand
Lately, microservices and DevOps are synonymous with each other. When you need an architectural approach to building applications, microservices provide this solution. Because microservices provide an architectural framework that is loosely coupled and distributed, the entire app won’t break when one team makes changes. One of the most significant benefits for using microservices is that it’s possible for development teams to build new components of apps rapidly. That way, they can continuously meet the ever-evolving business market.
Adam Bertram of CIO writes, “Microservices is especially useful for businesses that do not have a pre-set idea of the array of devices its applications will support. By being device- and platform-agnostic, microservices enables businesses to develop applications that provide consistent user experiences across a range of platforms, spanning the web, mobile, IoT, wearables, and fitness tracker environments. Netflix, PayPal, Amazon, eBay, and Twitter are just a few enterprises currently using microservices.”
What are the Benefits of Microservices Architecture?
The expectation is that companies are going to move to use microservices architecture as a way of increasing their delivery efficiency and runtime. However, you mustn’t be making these changes because other companies are making this move. Instead, have a firm grasp of the benefits of microservices architecture. They include:
Embracing automation and DevOps.
There’s a reduction in writing long, intricate lines of code.
Communication will improve among testing, QA, and development teams.
Finding and addressing bugs becomes quicker and easier.
Lightweight servers create faster startup times.
Independent scaling is available for each service.
See Problems Before Going Live
The cloud-native and microservices with DevOps means testing and production are integrated into the app lifecycle. Therefore, before going live, you can see problems by testing and troubleshooting. Organizations should keep in mind that, even though there is a multitude of benefits regarding microservice architectures, they’re not the ideal solution for all companies. The main reasons are they’re complex, require cultural changes, are expensive, and pose security challenges.
That doesn’t mean, however, microservice architectural frameworks doesn’t come with a set of benefits. For example, their design is such that they address the limitations found in monolithic architectures. Microservice architectures work toward modularizing an application into unique services to increase granularity.
Here are several benefits of using microservices architecture:
Companies can perform onboarding easier.
There’s less risk when microservices are implemented.
Microservices offer flexible storage for data.
Polyglot programming is enabled with microservices.
The reduction of clutter occurs.
There’s an increase in fault isolation and tolerance.
Companies experience an increase in the speed of deployment.
Scalability is available.
Security monitoring is simplified.
One of the most significant features of microservice architecture is that it’s scalable. You’ll find that it’s possible to scale each microservice independently. For example, if you need more power for one specific function, you can add it to the microservice providing that function. As demand changes, computing resources can automatically be increased or decreased as the changes in demand occur. As a result, it’s easier to maintain the infrastructure supporting your application.
It’s also possible to develop and deploy microservices independently. In doing so, development teams can focus on small, valuable features and deploy them. These deployments can occur without the fear of breaking down other parts of the application. Thanks to their small set of functionality, microservices are more robust and easier to test.
DevOps professionals know that every customer comes with a unique set of needs. Therefore, they commonly have configurations built in to meet those needs without separate applications deploying. Because microservices are separated and designed by functionality, it would be simple to toggle a feature on, allowing users to disable or enable particular microservices. When microservice architecture is designed correctly, it can be highly configurable without any worry of other parts of the application be affected.
CI Pipelines Will Become Obsolete
Currently, organizations and government entities are utilizing open source, and it’s the focus of their software development stacks. However, it wasn’t that long ago that open source was considered high-risk. With the recent acquisition of Red Hat from IBM and GitHub from Microsoft, which are homes of a variety of open source projects, this shows the general populace feels comfortable with open source. There will be increasing importance regarding DevOps and open-source practices. Specifically, DevOps teams will be using it in their Continuous Integration (CI) practices.
When you’re viewing a CI pipeline, it’s possible to see your app’s complete picture from its source control straight through to production. Now, CI isn’t your only priority. You also have to focus on CD (continuous delivery). What that means is, it’s time for your organization to invest its time and put effort into understanding how to automate your complete software development process. The main reason is that the future of DevOps is shifting away from CI pipelines and toward assembly lines.
What are CI Pipelines?
For those who don’t have a firm understanding of what a CI pipeline is, CI stands for Continuous Integration. Over the last few years, Continuous Integration has evolved tremendously. Initially, it launched as a system to automate the build and unit testing for each code; however, it’s evolved into a complex workflow. For example, the classic CI pipeline involved three steps, including build, test, and push. It’s evolved into other workflows, including CI pipelines that include forked stages, escalating, and notifications.
What are DevOps Assembly Lines?
DevOps Assembly Lines focus primarily on the automation and connection of activities several teams perform. These activities include CI for devs, config mgmt for Ops and infrastructure provisioning, deployments for multiple environments, test automation for Test, security patching for SecOps, and so on. Under most circumstances, an organization utilizes a suite of tools to automate specific DevOps activities. However, achieving CI is a challenging task because the DevOps toolchain is fragmented and difficult to glue back together.
Many teams adopt one of the following methods:
Gluing silos together using cultural collaboration.
Triggering one activity from another by writing ad-hoc scripts.
The second approach is better because it doesn’t introduce unnecessary human-dependancy steps or inefficiency. However, it only works well when working with one application using a small team.
Ultimately, DevOps teams solve this problem using Assembly Lines to address it by focusing on gluing together each activity into even-driven, streamlined workflows. These workflows can share state, as well as other information, easily across activities.
“There are significant benefits for companies to automate their software delivery process.” Manish Mathuria, CTO of Infostretch, explains, “advanced software development shops can put releases into production multiple times a day.”
What’s the Difference Between CI pipelines and Assembly Lines?
The CI pipeline features one activity in the entire Assembly Line. When breaking the project down into a chain of blocks, you can see a pipeline full of various activities. Each activity fulfills a specific need regarding configuration, notifications, runtime, tools integration, and so on. Different teams also own each pipeline, but they need to interact and exchange information with other pipelines.
Therefore, DevOps Assembly Lines are ultimately a pipeline created for pipelines. That means they must support:
Workflows across a variety of pipelines while quickly defining them.
Reusable and versioned workflows.
The ability to enable scaling for and rapid changes of microservices and (or) multiple applications.
Integrations with every source control system, artifact repository, DevOps tool, cloud, and so on.
Run-time to execute all pipelines.
Playbooks and Accelerators for standard tools and pipelines.
Manual approval gates or automatic triggers between all pipelines.
Serverless Technologies Will Provide Agility
One of the most significant problems DevOps teams had when working in earlier years is they worked separately in silos. These conditions led to a lack of transparency and poor teamwork. In many cases, DevOps teams need to merge, consolidate, and work together during the application’s lifecycle. Many times, this occurs right from development to deployment and throughout testing.
Delivering capabilities by leveraging functions as a service is the goal of DevOps professionals who have masters operating containerized workloads in complex ways. They’re achieving this goal by optimizing and streamlining this delivery. Throughout the next year, the depth and breadth on the focus of these functions will likely deepen. The main reason is that more professionals will recognize the benefits of working with serverless technologies as they become more comfortable leveraging containers in production.
“With the serverless approach it’s virtually impossible (or at least a bit pointless) to write any code without having at least considered how code will be executed and what other resources it requires to function,” writes Rafal Gancarz, “Serverless computing can be used to enable the holy grail of business agility – continuous deployment. With continuous deployment, any change merged into the code mainline gets automatically promoted to all environments, including production.”
Why Are Serverless Technologies Beneficial?
Some of the most significant ways serverless computing is providing benefits and agility to DevOps include:
better start-up times
improved resource utilization
However, despite these benefits, future DevOps professionals will become skilled at determining use cases whereby serverless computer and functions as a service are appropriate.
Agility and DevOps can work in conjunction with each other seamlessly without creating a hostile environment. The reality is the two working together create a holistic work environment by filling in the weaknesses each possess. In many workplaces, the future of DevOps is likely to compliment instead of supplanting Agile.
Creation of Modular Compartments
Often, Agile breaks down projects and creates modular and compartmentalized components. When there are more significant, organizational structures, this often leads to a lack of communication between teams and missed deadlines. Using DevOps deployment means internal structures of Agile teams that are kept in one place.
When thinking about the use of serverless computing, that doesn’t mean there aren’t any servers in use. Instead, machine resources are allocated by a cloud provider. However, the server management doesn’t have to be on the developer’s radar. That frees up time for focusing on building the best applications.
The cloud provider does everything else. When handling resource scaling, they make it automatic and flexible. Organizations are responsible for paying for only the resources they use, as well as when resources are used by applications. If organizations aren’t using resources, there’s no cost. Therefore, there’s no need for pre-provisioning or over-provisioning for storage or computing.
Serverless computing provides business agility because it makes it possible to create an environment whereby there are continuous developmental improvements. When organizations become agile enough for rapid decision-making, agility occurs and will lead them to success. Companies utilizing serverless computing to achieve DevOps will ultimately achieve greater agility.
Experience Changes Regarding IT
Organizations will also find that serverless computing doesn’t end with a path toward DevOps. It also leads to changes regarding IT, as well. For example, companies will be viewing the cloud differently. What that means is, because serverless computing relies heavily on the cloud, many long-standing IT roles will be redefined. Examples of these roles include architects, engineers, operations, and so on.
Traditional IT roles in a serverless computing world become less important. However, if that IT professional has a good working knowledge of the cloud and platforms, that becomes more important. That means this professional can accomplish more with the platform in comparison to a developer with expertise regarding their specialty, making it essential for organizations to have IT professionals who are skilled regarding the cloud.
According to Grand View Research, “The global DevOps market size is expected to reach USD 12.85 billion by 2025.” These statistics demonstrate the rising adoption of cloud technologies, digitation of enterprises to automate business processes and soaring adoption of agile frameworks. These statistics also point out how, when IT teams improve; it enhances the efficiencies regarding operations.
The future of DevOps is something that can be seen as a cultural shift, as well as something that brings conventionally disconnected components in the development, deployment, and delivery of software into a single loop. Organizations are finding that DevOps is replacing their traditional IT departments. Not only are the titles changing, but the roles are as well. Some of the roles have been eliminated, while others have been multiplied by the scale of microservice architectures. The execution of successful DevOps relies on teams communicating clearly with each other. The future of DevOps means the diminishing of manual approvals, but the human element will never vanish entirely.
With the rapid growth of cloud computing, the “as a service” business model is slowly growing to dominate the field of enterprise IT. XaaS (also known as “anything as a service”) is projected to expand by a staggering annual growth rate of 38 percent between 2016 and 2020. The reasons for the rise of XaaS solutions are simple: in general, they are more flexible, more efficient, more easily accessible, and more cost-effective.
Serverless abstraction and containers are two XaaS cloud computing paradigms that have both become highly popular in recent years. Many articles pit the two concepts against each other, suggesting that businesses are able to use one but not both at the same time.
However, the choice between serverless abstraction and containers is a false dilemma. Both serverless and containers can be used together, enhancing one another and compensating for the other’s shortcomings. In this article, we’ll discuss everything you need to know about serverless abstraction with containers: what it is, what the benefits are, and how you can get started using them within your organization.
What is Serverless Abstraction?
“Serverless abstraction” is the notion in cloud computing that software can be totally separated from the hardware servers that it runs on. Users can execute an application without having to provision and manage the server where it resides.
There are two main types of serverless abstraction:
BaaS (backend as a service): The cloud provider handles the application backend, which concerns “behind the scenes” technical issues such as database management, user authentication, and push notifications for mobile applications.
FaaS (function as a service): The cloud provider executes the application’s code in response to a certain event, request, or trigger. The server is powered up when the application needs to run, and powered down once it completes.
The FaaS serverless paradigm is akin to the supply of a utility such as electricity in most modern homes. When you turn on a light or a kitchen appliance, your consumption of electricity increases, and it stops automatically when you flip the switch off again. The amount of the utility is infinite in practice for most use cases, and you pay only for the resources you actually consume.
FaaS is a popular choice for several different use cases. If you have an application that shares only static content, for example, FaaS will ensure that the appropriate resources and infrastructure are provisioned, no matter how much load your server is under. The ETL (extract, transform, load) data management process is another excellent use case for FaaS. Instead of running 24/7/365, your ETL jobs can spin up when you need to move information into your data warehouse, so that you only pay for the run instances that you actually need.
What are Containers?
Containers are software “packages” that combine an application’s source code with the libraries, frameworks, dependencies, and settings that are required to use it successfully. This ensures that a software application will always be able to run and behave predictably, no matter in which environment it is executed.
Products such as Docker and Kubernetes have popularized the use of containers among companies of all sizes and industries. 47 percent of IT leaders plan to use containers in a production environment, while another 12 percent already have.
Serverless Abstraction with Containers
The goal of both serverless abstraction and containers is to simplify the development process by removing the need to perform much of the tedious drudgery and technical overhead. Indeed, nothing prevents developers from using both containers and serverless abstraction in the same project.
Developers can make use of a hybrid architecture in which both the serverless and container paradigms complement each other, making up for the other’s shortcomings. For example, developers might build a large, complex application that mainly uses containers, but that transfers responsibility for some of the backend tasks to a serverless cloud computing platform.
In light of this natural relationship, it’s no surprise that there are a growing number of cloud offerings that seek to unite serverless and containers. For example, Google Cloud Run is a cloud computing platform from Google that “brings serverless to containers.”
Google Cloud Run is a fully managed platform that runs and automatically scales stateless containers in the cloud. Each container can be easily invoked with an HTTP request, which means that Google Cloud Run is also a FaaS solution, handling all the common tasks of infrastructure management.
Because Google Cloud Run is still in beta and under active development, it might not be the best choice for organizations who are looking for maximum stability and security. In this case, companies might turn to Google Cloud Run alternatives such as Iron.io.
Iron.io is a serverless platform offering a multi-cloud, Docker-based job processing service. The flagship Iron.io product IronWorker is a task queue solution for running containers at scale. No matter what your IT setup, IronWorker can work with you: from on-premises IT to a shared cloud infrastructure to a public cloud such as AWS or Microsoft Azure.
Although they’re often thought of as opposing alternatives, the launch of Google Cloud Run and alternatives such as Iron.io proves that serverless abstraction and containers can actually work together in harmony. Interested in learning more about which serverless/containers solution is right for your business needs and objectives? Speak with a knowledgeable, experienced technology partner like Iron.io who can help you down the right path.
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.
Since releasing our flagship product in early 2011, Iron.io customers have enjoyed tightly coupled hosted solutions with Amazon Web Services (AWS). In addition customers are running Worker on-premise and in their own private clouds.
In the last year, an increasing number of customers have requested support for the Arm architecture both for on-premise deployments and in the cloud on AWS. Based on customer demand, we added Arm support on our roadmap. We’re happy to announce that Worker now supports Arm based architectures!
Customers that run their own hardware using Worker’s Hybrid deployment method, run Worker completely on-premise, or those that run on AWS, can now start diversifying their container workloads. We already have customers taking advantage of this release. It greatly increases the variety of workloads that can be run with Worker.
Iron.IO Worker Support for AWS EC2 A1
As you might be aware, Amazon announced a new Amazon EC2 A1 instance in November last year. It is based on AWS Graviton Processors. A1 instances deliver significant cost savings for scale-out and Arm-based applications such as Web servers, containerized microservices, caching fleets and distributed data stores that are supported by the extensive Arm ecosystem.
With Arm support, Worker now allows customers the ability to run workloads that require Arm based binaries. There could also be potential cost savings by moving your current workloads to these new instance types. That definitely depends on the resource load, though. It’s a good idea to read through the options (burstability vs no burstability, pricing, etc) and test out your specific workload before jumping in. Feel free to reach out to us if you’d like to discuss!
When creating a cluster in Worker, you’ll now see the availability of the A1 instance types. In order to run your workloads on ARM processors, you’ll simply need to use our new image: iron/runner:arm, rather than our normal iron/runner image. There’s also iron/runner:mplatform for cases where there could be multiple architecture types in the mix.
CivilMaps with Worker on Arm
CivilMaps runs Worker on-premise which allows for extremely low latency compute operations. At the end of their complex workflow engine, Worker sits as the data processing backbone, running containerized jobs at high concurrency.
CivilMaps is an Iron customer that does edge based HD mapping and localization for autonomous driving platforms. Last year they announced that they’d be moving their internal infrastructure to Arm. A quote about the move:
“Civil Maps is excited to announce that we’ve migrated our edge-based HD mapping and localization solution to the Arm® family of processors. Arm is the licensor to the largest ecosystem of automotive grade system-on-chips (SoC) and system-on-modules (SoM), with its chips already found in 85% of automotive electronic control units (ECU) on the road. Our team sees this as a key step towards building a truly scalable platform for self-driving car developers. The industry still has a long way to go, but we believe that the arrival of cost-effective, production-grade systems for level 4 and 5 autonomous vehicles just got significantly closer.”
In the next few months we’ll be publishing more blog posts about our Arm support and sharing more customer success studies in depth. There are customers utilizing Worker in many unique ways and we believe our new support for Arm is going to open the door for many more.
Kubernetes is one of the most popular choices for automating and managing Linux container operations. Originally developed by Google, the open-source Kubernetes project is now in use by some of the world’s largest enterprises. These include IBM, Nokia, Comcast, and Samsung.
With the rise of Kubernetes itself, we’ve also seen growth in accompanying services that aim to make it easier for developers to use Kubernetes. Amazon EKS is one such service.
Since its release to the general public in June 2018, Amazon EKS has generated a good deal of buzz among Amazon Web Services customers. But is it worth the hype, and what are the Amazon EKS alternatives out there?
In this blog post, we’ll go over everything you need to know about Amazon EKS. We’ll include brief history, the pros and cons, user reviews, and a look at your alternative options.
What is Amazon EKS?
Amazon EKS (Elastic Container Service for Kubernetes) is a managed service from the Amazon Web Services cloud computing platform. Specifically, Amazon EKS aims to make it easier for AWS users to run Kubernetes without needing to install or manage their own Kubernetes clusters.
“What exactly is Kubernetes?” you might ask. Kubernetes is an open-source platform for managing software applications that have been packaged into so-called “containers” along with their libraries, dependencies, and settings. Containers make it easier for developers to ensure that their code behaves predictably even when running in different IT environments.
Amazon EKS takes care of Kubernetes deployment, management, and scaling, freeing users from having to handle these onerous technical details. Microservices, batch processing, and application migration are just a few of the ways that Amazon EKS might help organizations.
Amazon EKS Pros and Cons
Now that we’ve answered the question “What is Amazon EKS?”, we’ll discuss whether the Amazon EKS service actually meets the expectations outlined above. In this section, we’ll go over the pros and cons of Amazon EKS.
Amazon EKS Advantages
Good for AWS customers: Amazon EKS may be a wise choice if you’re very sure that you want to stick with AWS well into the future. If you migrate to another public cloud provider like Microsoft or Google, you’ll have to rework your operations all over again.
Automated control plane management: The Kubernetes control plane is a collection of processes that are running on a single cluster of computers. Amazon EKS handles the task of control plane management, taking it out of your hands.
Serverless architecture: Amazon EKS uses serverless architecture, which means that you don’t have to worry about manually overseeing your server rentals. You can write and deploy code without having to worry about managing or scaling the underlying infrastructure.
Amazon EKS Disadvantages
Not “cloud-agnostic”: Amazon EKS is only a solution for those companies that want to perform work on AWS. It’s a poor choice if you want to easily move applications between multiple public cloud providers. You’ll have to handle the task of container orchestration on these other clouds as well.
Not dynamic: Even if you want to use Amazon EKS as part of a larger multi-cloud puzzle, you’ll still need to handle the administration part yourself. This can pose challenges for dynamic multi-cloud models, where applications need to move quickly and easily between different cloud providers.
No integration: Of course, as an AWS-exclusive service, Amazon EKS doesn’t offer integrations with other managed Kubernetes services, and it isn’t likely to do so any time soon.
Amazon EKS Reviews
In general, Amazon EKS has been well-received by many AWS customers. On the tech review platform G2 Crowd, Amazon EKS reviews currently have an average score of 4.3 out of 5 stars based on 10 user ratings.
According to these reviews, the greatest benefit of Amazon EKS is the ability to abstract away the underlying complexities of Kubernetes. One user says: “The best thing is that I don’t need to install and operate my own Kubernetes control plane. Instead, it makes work easy by giving us an API endpoint from which we can directly connect to the EKS managed control panel.” Another user writes approvingly that Amazon EKS “automatically manages the availability and scalability of the Kubernetes masters.”
However, the Amazon EKS reviews on G2 Crowd also point out two main disadvantages of the service: the pricing and the learning curve. Multiple reviewers note that Amazon EKS can be costly, especially for smaller businesses:
“It is a little expensive for business…”
“Can get pricy for small businesses”
“I dislike the pricing structure – maybe lower prices for smaller-sized businesses and those using it less, so that more could roll it out.”
In addition, some reviewers complain that the Amazon EKS learning curve can be challenging for new users:
“It takes a bit of an adjustment to learn the ropes of the whole process and overall general concept.”
“Can add more documentation on errors, it was hard to debug some errors. I had to rely on public sites to do it.”
“The configuration learning curve can be a bit steep for some.”
Another user frustrated by the Amazon EKS difficulty is Matthew Barlocker, software engineer and CEO at the AWS infrastructure monitoring company Blue Matador. He writes: “I found more negatives than positives… EKS is too complicated to set up to be valuable for newer users, and too fragile to be valuable to a legitimate DevOps person.”
Given some of the issues discussed above, it’s understandable that some customers might want to find Amazon EKS alternatives.
The two other major cloud players, Microsoft Azure and Google Cloud Platform, both offer Kubernetes services that are very similar to Amazon EKS: Azure Kubernetes Service and Google Kubernetes Engine, respectively. Both offerings are well-reviewed on G2 Crowd, although some users mention having similar learning curve issues.
For the 85 percent of enterprises that operate in multicloud environments, however, services like Amazon EKS and Google Kubernetes Engine may not be enough to keep them satisfied. That’s why Iron.io offers IronWorker. IronWorker is a container-based platform that can easily be configured to work with Kubernetes as well as all the major public cloud providers.
Just like Amazon EKS, IronWorker’s goal is to handle all of the complicated technical issues with Kubernetes. This allows developers to produce more valuable and meaningful work. IronWorker has a variety of deployment options. These options can fit the needs of any organization, including shared infrastructure, hybrid cloud, dedicated servers, and on-premises. IronWorker is a matur feature-rich alternative to Amazon EKS. It lessens the IT burden and lets you focus on higher-quality final products.
Amazon EKS is a popular option for teams that want to simplify their Kubernetes deployments, but it’s not necessarily the best choice for all organizations. For example, companies that are already heavily invested in Microsoft Azure or Google Cloud Platform may opt for the offering from their preferred cloud provider.
Meanwhile, companies that are looking for flexibility across multiple clouds (including private and hybrid cloud setups) would do well to check out services like IronWorker.
Interested in learning more about Iron.io? Give it a test drive with a free, full-feature, no-obligations trial for 14 days. Contact us today to request a demo of IronWorker or IronMQ.
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.
In short, it rocked! We had a great time with old and new friends alike. Thanks to everyone who made it awesome, not the least of which were our co-sponsors CircleCI and Sauce Labs. From interesting (and sometimes downright hilarious) conversations, to just shooting some billiards, it was a memorable and enjoyable night.
Iron.io’s swag was off the charts! (Did it have anything to do with our branded flasks being full of bourbon?…Nah, definitely not. No way.) Our shirts were also a hit, so a big shout out to our creative department for their efforts in creating them. Was it the best in DockerCon? Who knows. Was is pretty cool to give away some free Iron.io stuff to DockerCon attendees and friends? Yes.
We look forward to the next event with our amazing clients, friends and associates! Until next time, so long!
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.