Enterprises are investing heavily in their IoT efforts, so much so that the total IoT market is expected to grow to $1.7 trillion by 2020, compared to its $656 billion in 2014, according to research firm IDC. The research firm Gartner estimates that there will be 8 billion business-connected IoT devices by 2020. With so many devices coming online, enterprises can expect a lot of changes and incremental demand on their infrastructure.
Those that do it right will be able to drive innovative solutions for themselves and their businesses. But what does such an innovative friendly IoT infrastructure look like? For that answer, we turned to Flux7 co-founder, Aater Suleman.
We’ve recently spoken about building innovation friendly IoT infrastructures. What does an innovation friendly IoT infrastructure mean to you?
Building an innovation friendly IoT infrastructure is about building infrastructure in a way such that enterprises can deliver changes to IoT devices more quickly. It’s about building an IoT infrastructure that is ready for future computing demands, but can also support future agility and innovation. It’s about being able to innovate faster, and if an enterprise wants to try something new, their infrastructure is designed and managed in a way that will support them. The enterprise doesn’t have to boil the ocean if they have a new idea that they want to try. They are never waiting for IT if they want to try new ideas. To me, that is an innovation friendly IoT infrastructure.
What does that look like in practice?
In practice, enterprises with an innovation friendly IoT infrastructure can deploy software quickly, both on their internal user side and on their business customer facing side.
For example, if every time a business wanted to try a new feature, they had to call every single device in order to update it, that is just not something that is going to happen in reality. However, if it’s easy to push out feature updates, then it’s something that the business can and will do. And the result will be that they can innovate much more quickly. It’s about having the right support infrastructure in place, too, so that they have the full end-to-end testing that they need. This way when the new feature is deployed, there’s no worry that it’s going to break anything.
It also looks like modern software development practices. Best practices don’t go away because of IoT. These all still apply, such as having continuous integration and continuous delivery pipelines. And I’d say that being able to do conduct continuous integration and delivery is a prerequisite in innovation. Also reducing the cost of failure by being able to quickly revert back to prior states should something go awry. This is what will enable enterprises to innovate faster.
Mistakes are never fun to have to fix, but I imagine if the IoT infrastructure isn’t designed right, it is much more difficult to repair things in the field?
Correct. But even in the field the right infrastructure will support rapid and safe changes. There are ways to architect the system so that it can tolerate failure in the field. The key is to apply a basic principle to maintain backward compatibility on the different versions. This way, if one deploys an incremental version and it doesn’t perform well, a simple signal can be sent to the device and it can be reverted back to a prior version. It does not have to require a full delete of everything. The same rule applies on the infrastructure side. If a device cannot be updated or should an issue arise, there still should be backward compatibility.
That's an important aspect of the innovation friendly design. Having the ability to be able to do things in an incremental way. This can be for adding features, or even how features are deployed to users. For instance, a small test of 10 percent of customers, chosen randomly, can be a lower risk way to test out a concept. After it goes well, then roll everything out.
In my interviews with end user organizations, I’m still surprised to run into those that are designing and deploying their IoT infrastructure in-house. What are some of the things you’d say to those enterprises that want to manage their IoT on their own internal clouds?
There's no downside to doing it all in the cloud. But there is to building it on-premises. If you build an IoT on-premises infrastructure the enterprise will have to manage the elasticity itself. They’ll have to manage all of the connectivity and the network planning. They have to make sure that this is all done very carefully.
And making a mistake anywhere along the way can create big problems down the line. When enterprises run out of elasticity, they can end up spending a lot more budget unexpectedly. This is because they will be forced to make less than optimal decisions. One example is having to rapidly add more storage and hope downtime is averted. But there are other ways, too. Sometimes when one over-provisions, developers realize that they have so much extra capacity that they can get away with writing sloppy and less than optimal code. And when you run up the scalability wall, there are no options left, because the enterprise has to put up more servers or ask everyone to revamp their code.
Another is that the enterprise will have to be prepared to build everything itself. This is going to consume a lot of effort and enterprises will no doubt make mistakes that cloud providers and other vendors have already learned to avoid. And there are already many solutions built by cloud platforms that solve some of the most common challenges: how is flaky internet handled? How about good security? How is device authentication best managed? If you are attempting to do this all on premises, and build your own solutions, you can run into costly mistakes hence the level of caution shall be a lot higher. Therefore, a cloud-based path may be a safer and cheaper option for starters.
For additional advice on building innovation friendly IoT architectures, please download our white paper, Succeeding with the IoT-Ready Infrastructure..
In our last article , we took a look at why Docker is a natural fit for microservices and the top five process design points to consider when planning for a Docker-based microservices deployment. Today we will dive into the top five technology design points that should be considered in the planning stages. Doing so will help you avoid potential stumbling blocks that when not thought through in advance can really cause headaches down the road.
We are excited to see that today our customer, Rent-A-Center, has been featured on the AWS Blog. Rent-A-Center was interested in quickly introducing a new ecommerce platform that was secure, PCI compliant, and highly scalable to ensure it would cater to online web based demand.
As AWS consultants steeped in DevOps best practices, Docker, and the forward edge of new technologies and architectures, we often get asked about microservices. One of the most common questions we field is around potential stumbling blocks to a Docker-based microservices approach. This is a really smart question as there are several considerations that when not thought through in advance can really cause headaches down the road.
Before we talk through these top considerations, however, let’s first review why so many organizations are considering microservices in the first place. As you likely know, the idea behind microservices is that instead of writing an application as a single monolithic code base, developers can break it into smaller, autonomous services. This allows for more agility and greater autonomy amongst different teams, allowing them to work in parallel accomplishing more in less time.
Despite many of the valid concerns surrounding enterprise Internet of Things (IoT) deployments, there’s no slowing its momentum now. By some estimates there will be more than 50 billion intelligent and connected devices by the year 2020, and within a decade, according to a McKinsey study, these devices will spark $11 trillion in economic value. Despite uncertainty around return on investment, regulations, or the ability to execute because of technological barriers, the move to connect and add intelligences to disparate and distributed devices remains strong.
AWS launched EC2 Run Command in October 2015 to provide a simple way of automating common administrative tasks like installing software or patches, running shell commands, performing operating system changes, managing local groups and users, altering configuration files and more in Windows instances. AWS quickly followed the launch with the same feature for Linux instances, and in May 2016, they added the power to Manage & Share Commands, and the ability to use additional predefined commands along with any custom commands that users have created for their accounts.
In addition to the announced CloudFormation YAML support, AWS also announced cross-stack references for CloudFormation. (For Flux7 commentary on YAML support, please see our blog post earlier this week here.) As our AWS experts work daily with CloudFormation, we were very interested in this news and couldn’t wait to roll up our sleeves and take a look for ourselves.
In our blog last week we told you that AWS CloudFormation has grown its support beyond JSON to include YAML. Prior to the announcement, our AWS consultants had been writing in YAML and used an in-house YAML CloudFormation generator to help us avoid the typical pain points associated with JSON. We promised in that article to share with you instructions on how to convert existing JSON CloudFormation templates into YAML and are delivering on that promise today.
YAML and AWS CloudFormation: Simplifying Template Creation
Today AWS announced that CloudFormation will now support YAML. As big fans of YAML, we have been testing this new feature and are not disappointed in the results. Prior to this announcement, JSON specifications were used to write CloudFormation templates. However, we had been writing in YAML and using an in-house YAML CloudFormation generator which helped us avoid the typical pain points associated with JSON.
Amazon Web Services (AWS), the largest public cloud currently available, has added the ability to use the Elastic Compute Cloud (EC2)’s powerful “Run Command” feature with a single log-in to execute commands in multiple locations, including EC2 instances, on-premises servers or virtual machines (VMs) from other cloud providers. Prior to this, it was necessary to log into each instance, server or VM separately.