devopsy.kinsta.cloud

Category: IT as Code

  • Hybrid Low-Code: The Next Step in App Development

    Hybrid Low-Code: The Next Step in App Development

    The promise of low-code development has long been the ability to develop business-critical applications by humans with little programming experience. In fact, over the past year or two, the lines between low-code and no-code have become increasingly blurred. Low-code platforms have incorporated more and more functional no-code features to increase the efficiency of the developer even further. Some of these platforms have become so intuitive to use, the idea that anyone can create an app has evolved into the idea of citizen developers. But is low-code really the be-all and end-all when it comes to app development? Seems the answer to that is, “It depends.”

    It has become glaringly obvious that exclusively no-code platforms can’t create complex applications. But then again, these platforms were never really designed with that kind of functionality in mind. No-code can be a highly valuable, rapid prototyping tool as well as a decent tool for very small, very specific apps. These apps would be best suited for intradepartmental use or to extend the functionality of very specific SaaS tools. No-code is not going to power your business-critical applications, and a not-quite-a-developer is not going to lighten your IT load.

    But what about low-code? Can low-code be the bridge between citizen developers and the ever-growing list of backlogged apps? Maybe. Using citizen developers comes with a whole heap of issues that need to be addressed. While this topic can be the subject of an entire blog in its own right, I can quickly highlight the major issues to consider. How much of a citizen developer’s time should be dedicated to app development? Is using citizen developers going to create backlog issues in their primary departments? Who is going to train and support citizen developers? How is IT ensuring that citizen developer-created apps are secure, scalable and extendable? As great as citizen developers sound, they still are not a definitive solution.

    A realization has dawned in the low-code industry. Low-code can’t be and do everything, but it can be a useful development tool to speed up application development. However, most low-code platforms are in their own development silos, separated from other development tools with their own IDEs. Instead, one idea is to create a quick and easy-to-use user interface, drag and drop some app functionality, and then finish complex apps in a language the low-code platform can integrate with, such as Java, or via a Visual Studio plug-in. Even the biggest and best low-code vendors admit that just using low-code isn’t going to power your business.

    Low-code can’t be everything, but it can be a major part of everything. It just needs to look different from how most low-code platforms are designed. Using a hybrid low-code approach will allow organizations to truly use low-code from start to finish in the app development process. Rather than looking at low-code as a separate tool in the development process, a hybrid low-code approach brings low-code inside an IDE where traditional coding methods are still used.

    Is hybrid low-code the future of app development? I would say hybrid low-code is a next step in the evolution of app development. Low-code development tools shouldn’t be isolated in their own IDEs. It can be frustrating to leave a low-code IDE to finish the app in another IDE, and then have to connect the different elements into one cohesive app. As you can see, efficiency is reduced every time a developer leaves one IDE for another. Hybrid low-code views low-code as a tool inside a bigger development toolbox. It is there when convenient, but a developer isn’t forced to use just low-code. They can import already created assets from other languages, hand-code complex solutions, drag-and-drop when it makes sense, and create all the necessary components of a progressive web app with a click of a button.

    While there might be a profound realization that “traditional” low-code can’t do everything it originally promised, hybrid low-code could, instead, fulfill that promise.

  • CloudBolt Software Aims to Bridge DevOps and IT Divide

    CloudBolt Software Aims to Bridge DevOps and IT Divide

    CloudBolt Software today released a Winter update to its cloud management platform that aims to bridge the divide between DevOps teams and traditional IT administrators.

    IT administrators can now employ the CloudBolt platform to invoke the open source Ansible framework for automating IT processes and workflows using a graphical user interface (GUI) surfaced via a OneFuse Ansible Tower module.

    Additionally, the OneFuse Scripting module will now make it possible to automate script creation for anyone who creates a script using, for example, Terraform, and package that script in a way that IT administrators can invoke via a graphical tool.

    Jeff Kukowski, CEO of CloudBolt Software, said the goal is to make it easier for IT teams across the organization to reuse code created by a DevOps team. OneFuse provides IT with a codeless integration tool. In addition to the core cloud management platform, CloudBolt Software also provides access to a Kumolus service that enables IT teams to optimize cloud costs and provides additional governance capabilities such a generating an audit trail.

    Other capabilities added in the Winter release include deeper cost optimization analysis for VMware vCenter and Microsoft Azure environments, support for the latest release of VMware vRealize and additional C-level dashboards and reports.

    As the number of workloads deployed in production environments increases, there is going to be a greater need for some form of détente between DevOps teams and traditional IT administrators. Site reliability engineers (SREs) can typically manage a much wider range of workloads than an IT administrator. However, SREs are both expensive and hard to find and retain. IT organizations will need to find a way for IT administrators that, at best, have limited programming skills, to pick up some of the slack.

    Those IT administrators can play a critical role in minimizing the number of misconfigurations arising from provisioning IT infrastructure as code. Misconfigurations as a result of developer mistakes are rife across the cloud, and IT administrators are more inclined to check for these than are developers who are racing to deliver their next application.

    The truth is, there are a wide range of tasks that DevOps teams would just as soon see managed by IT administrators, especially if a script or runbook that addresses common issues has already been created. The trick is making that script or runbook easily accessible.

    In the meantime, IT organizations are racing to keep up with complexity in IT environments, often by applying automation at scale in a way that is both repeatable and well-documented. Whether IT professionals like it or not, the days of writing automation scripts and failing to document them are coming to an end. The real issue is ensuring that what does get automated actually works as expected, each and every time a script is applied.

  • AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics today announced its agent software, which it provides as part of its observability platform, now has the ability to enforce application security policies.

    Developed in collaboration with the security business unit of parent company Cisco, the Cisco Secure Application offering, available from AppDynamics, can detect attacks, identify deviations in application behavior and block attacks automatically.

    Gregg Ostrowski, a regional CTO for AppDynamics, said the goal is to make it simpler for IT teams that employ AppDynamics for monitoring and observing their IT environments to also embrace DevSecOps best practices. In effect, IT teams can now piggyback security for application runtimes on their existing investment in AppDynamics, Ostrowski said.

    The AppDynamics approach provides the added benefit of easy integration with the Cisco security tools to improve collaboration between DevOps and cybersecurity teams, Ostrowski said. Security details correlated with the application topology make it easier to share context in a way that identifies the actual business relevance of any security event, he added.

    As organizations accelerate digital business transformation initiatives, Ostrowski said the need to embrace DevSecOps best practices is becoming more urgent. The level of risk attached to these types of projects is significantly higher than with previous generations of applications, Ostrowski said.

    While most organizations appreciate the need for greater application security, there’s a debate about how best to achieve that goal. There’s general agreement that developers need to be more involved. However, shifting responsibility for application security to the proverbial left often comes at the expense of developer productivity. AppDynamics is making a case for enabling IT teams, that may already rely on its application performance management (APM) platform, to enforce policies defined by the cybersecurity team.

    Of course, there’s still a need to provide developers with the tools required to write more secure code in the first place. The debate is over how involved in the cybersecurity management process developers need to be after applications are deployed in a production environment.

    Arguably, the goal should be to enable both teams to accomplish their respective tasks in a way that doesn’t require a constant stream of meetings and updates. In the event a vulnerability is discovered, it’s critical for security teams to determine the threat level that vulnerability represents. Otherwise, remediation of that vulnerability will be just one more item in a long list of patches that developers are already working on.

    Regardless of approach, there are now myriad ways to improve overall application security. In effect, the same defense-in-depth approach that IT organizations have relied on to secure network perimeters can now be applied to application security as applications are both constructed and deployed. The most significant challenge is not so much finding the tools required to improve application security, as defining the processes through which best practices can be consistently applied.

  • OpenAPI Specification: Perception vs. Reality

    OpenAPI Specification: Perception vs. Reality

    The OpenAPI Specification (OAS) (formerly known as the Swagger specification) provides a way to describe and document REST APIs and their components. It includes details on endpoints, their operations, parameters needed for the operations, expected responses for every operation, authentication methods and even annotations. OAS is an easy format to learn and read, and can be understood by both humans and machines. As you might imagine, this kind of “accessible” documentation is useful and beneficial in a number of different use cases for both development and security teams.

    Developer Relationships With OAS

    For developers, OAS can be used to generate documentation for APIs. Proper documentation can help other developers figure out how best to integrate and use these APIs with their own application.

    Even so, many developers have a love/hate relationship with OAS. Let’s face it, documenting is a far cry from developing. Although it is easy to learn, the actual act of documenting is tedious, manual and time consuming. Frankly, it’s probably one of the least glamorous parts of a developer’s job, and, therefore, many developers only do the absolute minimum. As a result, OAS can be incomplete or, in some cases, missing entirely. Not to mention, when the API is updated, how often is the OAS updated, too?

    In the case of incomplete or nonexistent documentation, developers will muddle through with trial and error, even though this can slow down the development process.

    If out-of-date OAS proves an annoyance for dev teams, what’s the impact on security?

    Security’s Relationship With OAS

    OAS can be consumed by both humans and machines, and both are critical for security’s use of OAS.

    OAS helps security teams (humans) become aware that the API exists, since its documentation is often part of the CI/CD process.

    By examining an OAS file, a security team can understand what the API is supposed to do and, from that, determine if it conforms to or violates the organization’s security policy. As an example, security teams might use the OAS to make sure that authentication and authorization are being implemented correctly, and that sensitive data, like PII, is not being exposed.

    Security teams might also deploy tools (machines) that use the OAS to enforce policy based on what’s in the documentation. As an example, the OAS may specify that, for a particular parameter, a string should be expected; it should be no more than four characters and it should contain only letters and numbers with no special characters. By validating input based on what is defined in the OAS, security tools can check that the API does what developers intend it to do.

    This plan sounds great on paper, but …

    Perception versus Reality

    Imagine a perfect world, in which every API is well-documented as part of the development process. As that API makes its way through the development pipeline, it does so hand-in-hand with an associated OAS. At the appropriate time, before production, security is made aware of the API and the OAS, the team evaluates the details, validates that the API matches policy, gives the thumbs up and the API goes into production. Security and development teams live in harmony and everyone is happy.

    We don’t live in a perfect world. Instead, we must deal with questions such as:

    • Does the OAS exist? In the most extreme cases, the OAS doesn’t even exist. It was never created as part of the development process, so it can’t be used for any sort of awareness. These misses happen more often than you think, giving rise to the problem known as shadow APIs. These APIs slip through the cracks, and make it into production with no documentation at all. While you might be saying to yourself, “Our company would never let this happen!” you should also consider that numerous APIs are stood up by development teams as a test, as part of a beta or as a quick-and-dirty way to get something done. There are more of them than you think, and these shadow APIs create unrealized risk.
    • Is the OAS complete? In slightly less-scary territory, let’s consider an incomplete OAS. You might be saying to yourself, “We have a top-notch development team, well-defined development processes and strict policies around documentation. No API makes it into production without an OAS!” Perhaps, but the devil is in the details, and those details are often missed. I’ve worked with countless customers who have happily and confidently produced an OAS in which critical details don’t match the reality of the API. Sometimes they’re not complete. Sometimes they’re missing all together. The industry calls these missing details shadow endpoints. Yes, someone did produce an OAS, and security was aware of the API, but a lot of critical detail is missing.
    • Is it being kept up-to-date? Development cycles seem to be moving faster and faster, and as documentation is one of the least glamorous parts of a developer’s job, updates can be missed, dismissed or, at the very least, lag behind. We commonly see multiple versions of an API, and the OAS does not reflect the new capabilities of the latest version.

    While a non-existent or outdated OAS presents a modest concern for API visibility, it creates a substantial concern when trying to serve as the foundation for API security.

    You take a huge risk if you depend solely on OAS for security. More often than not, an OAS is not accurate, lacks critical details and is only as useful as the data you feed into it. Gaps, including shadow APIs, leave out critical details, making enforcement impractical.

    The inaccuracy of OAS leaves customers with two choices. You can either enforce security policies based on strict adherence, and risk blocking legitimate traffic, or you can enforce based on loose adherence and risk letting attacks through. In either scenario, your organization is unduly vulnerable, and significantly less secure than your dev teams intended or your security teams would like.

    OAS is Only a Starting Point

    OAS provides a great starting point for documenting your APIs. Don’t make the mistake, however, of basing your API security strategy on what’s in your OAS. It’s simply not accurate enough. Taking that approach will leave your company’s vital data and services at the mercy of API attackers who will quickly know more about your APIs and what they expose than your OAS does.

  • Using Automation to go All-Digital, Fast

    Using Automation to go All-Digital, Fast

    Before the pandemic, digital transformation was a five-year plan for many companies — or in some cases, a distant vision that kept getting kicked down the road. Now, companies in every industry face an urgent imperative to adapt to an increasingly online-first world: If you don’t go digital, fast, you’re simply out of the game.

    Increasing productivity has been critical for companies as they make this shift. But too often, speed is hindered by time-consuming and repetitive processes that companies can and should easily automate. By automating mundane tasks, employees and businesses can focus on what really matters — increasing scale in today’s work-from-anywhere world, and improving experiences for both employees and customers.

    The Benefits of Automation

    Fundamentally, automation is about digitizing existing business processes to streamline results, and it will be a key element in helping businesses survive and get back to growth. Until now, many companies have focused on applying these tools to the front office: sales, marketing, commerce and supply chains. With most employees now working remotely, it’s harder than ever for team members to do their jobs efficiently. Automating the back office and improving the employee experience is key for businesses to achieve the speed they need to thrive right now.

    Here are three key advantages of bringing automation to the back office:

    1. It improves productivity.In virtually every industry and role, employees are still spending hours every week on mundane and labor-intensive tasks, such as data entry. Automation can speed up these repetitive tasks and streamline lengthy processes, freeing employees up to focus on the “human” aspects of their jobs, like interacting with customers, planning ahead, making decisions or learning new skills. By taking over routine tasks and allowing employees to concentrate on what matters most, automation makes workers more efficient and productive.
    2. It increases scale.There’s only so much an employee can do manually. The time-consuming processes that worked yesterday can’t scale to meet the demands of an all-digital environment.  Automating repetitive tasks means that employees can achieve more in the same amount of time, allowing them to scale their workloads. With time-consuming tasks being taken care of in the background, workers can spend their time on more meaningful work and customer relationships.
    3. It enhances employee experience.Nobody enjoys entering numbers into a spreadsheet. An often overlooked aspect of automation is that it leaves employees more satisfied and engaged with their companies and their jobs. Having fewer tedious tasks on their plates gives employees the chance to tap the skills that machines aren’t as good at, like creativity, communication and decision-making. This is especially beneficial at a time when most employees are juggling more responsibilities at work and at home. Making a more valuable contribution and more meaningful connections is not only rewarding for employees, but also translates to higher satisfaction among the customers they interact with.

    Real-World Examples

    Not everything can be automated, but there’s a lot of room to take the drudgery out of most roles. Take onboarding, for example. Traditionally, when a new hire started, everything happened in person: They attended an orientation, picked up their laptops at the tech bar, met with benefit providers — all of which required orchestration on the part of human resources. With automation, all of this manual coordination can be replicated with an intelligent workflow capable of guiding employees through an onboarding process customized to their specific role and location.

    In another example, HR departments are facing an unprecedented volume of queries about policies around caring for children and other dependents. Using low-code development, companies can easily set up automated, online bots to handle frequently asked questions and guide employees through processes needed to enroll in new services. Automating these queries with bots not only makes the employees themselves more productive, but it also delivers better experiences for both the HR team and the employees seeking answers.

    Automation is Here to Stay

    In today’s world, there is no alternative to a digital business model. Automation is the recipe that will help companies achieve the speed they need to survive now and the edge they need to thrive in the future.

    And there is no turning back — automation is here to stay, regardless of the trajectory of the pandemic. The process of change is never easy, but done right, automation not only leads to a more agile workforce, but also to a happier one.

  • vFunction Automates Conversion of Java Apps to Microservices

    vFunction Automates Conversion of Java Apps to Microservices

    vFunction has developed an eponymous platform capable of automatically converting a monolithic application written in Java into a set of microservices. The startup is emerging from stealth mode today.

    Fresh from raising $12.2 million in seed funding, vFunction CEO Moti Rafalin said the company’s platform employs dynamic analysis, static analysis, data science and automation to enable IT teams to reengineer, in a repeatable fashion, the source code used to create monolithic Java applications.

    As part of that process, vFunction also detects and eliminates code that is no longer executed to reduce the footprint of an application, minimize security risks and overall maintenance tasks.

    The vFunction platform is deployed as a server that communicates with agent software injected into the legacy monolithic application. The server then creates a microservice that is scanned by additional tools to determine how best to optimize it to run on, for example, a Kubernetes cluster based on the Red Hat OpenShift platform, said Rafalin.

    IT teams can also employ vFunction to determine which monolithic applications are better suited to being converted into a set of microservices that can be automatically extracted into separate compilable projects. Each project comes with an estimated timetable for completion that can be accessed via a Modernization Factory Dashboard and Application Complexity Assessment tool provided by the platform.

    Rafalin said most monolithic applications are made up of large amounts of ‘spaghetti code’ that was added over multiple generations by different development teams. Manually analyzing that code as part of an effort to refactor a legacy application would require weeks of effort, Rafalin said. As such, the rate at which most organizations are re-engineering applications is extremely slow, he said.

    In fact, it’s not unheard of for IT organizations to to start, but quickly abandon such because the time and effort required proved too costly. vFunction claims its automated, domain-driven processes accelerate manual refactoring by a factor of ten, resulting in a savings of anywhere from $300,000 to $500,000 per application.

    Pricing for vFunction is based on a per-application model. The company has also established alliances with system integrators such as HCL Technologies, Tata Consulting Services and Wipro that are regularly contracted by IT organizations to refactor their applications.

    Of course, not every monolithic application needs to be converted into a set of microservices. However, most monolithic applications have components that would be easier to maintain and support as a distinct microservice. Organizations, in general, are embracing microservices to build applications that are more resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than crashes altogether. The challenge is that, over time, the dependencies that can exist between hundreds of microservices can be more challenging to manage than those of the monolithic application being replaced.

  • DevSecOps Implementation: EDR/XDR

    DevSecOps Implementation: EDR/XDR

    We mentioned host intrusion detection and network intrusion detection in an earlier blog, and mentioned firewalls a couple of times in passing. Let’s delve a bit into the history to understand how these tools’ functionality has evolved over time.

    On the host side, we had virus detection, in one form or another, from early in the evolution of the Internet. The idea being that, if an antivirus program could scan your files, it could help protect you from malicious applications. Applied to an organization, if antivirus applications could scan all users’ desktops, it could help protect the organization. And it did kind of work. Most organizations were protected, at one point or another, by their antivirus software. Then, they realized the need to see more than what simply scanning files could show. A file that looked innocent on disk could assemble malicious code while executing, so runtime environments also needed to be watched. Generally speaking, the same antivirus companies led the charge into runtime protection. But there is more to protecting systems than simply looking at running applications. Scripts, even database entries, could be made malicious, and activity over time could indicate a bigger problem than a virus – an intrusion. This problem was the reason host intrusion detection was born. The idea that all of your system(s) needed protection all of the time created a mostly agent-based environment that monitored several aspects of the running system to watch for suspicious activity.

    On the network side, firewalls were implemented early in the growth of the Internet to allow limited access to corporate resources over the network. If no one ever needed to telnet to the machines on subnet X, the telnet port for subnet X could simply be blocked at the firewall, and no sleep need be lost over attempts to connect. Almost immediately after their inception, firewalls started logging attempts to access ports, and this information was made available to network administrators to review. This had an interesting impact on the management of hosts, because now, the firewall could inform network administrators if one of the internal hosts was constantly attempting to do something it shouldn’t be – possibly indicating an intrusion or a bad employee (more often than not, it turned out that undertrained, curious employees were just poking around). But firewalls – whether using whitelist or blacklist methodology – were fragile and/or interruptive. They also simply plugged holes in the perimeter without being proactive. That is when some bright people realized that, if you monitored streams running through the firewall, you could detect attacks and intrusions and offer admins proactive information about potential threats. That was the genesis of network intrusion detection (at least, as with all of these, as much of it as I can cram into a blog).

    But as time has moved on, there was a need for more. Network intrusion prevention was tried, but most organizations don’t want automated systems cutting off connections for fear of impacting real users. While it is still around, it hasn’t gained all that much traction. The next step was to “connect the dots,” so to speak. If the HIDS on host A was detecting a suspicious pattern of behavior, it only made sense to have the HIDS on the other hosts in the network take a look for similar behavior. Command and control of cross-HIDS installs is at the heart of endpoint detection and response (EDR), which gathers information from multiple HIDS agents and correlates it to get a more holistic view and alert on activity that a single host might not have noticed (a super simplified example: if the same user account tries to get super-user privileges with a single attempt on a dozen machines. HIDS might not raise a high-priority alert for a single attempt, but EDR sees twelve attempts on twelve different machines, not just the one on a given box, and can raise a high-priority alert).

    Extended detection and response (XDR) extends this information amalgamation and analysis to the network side, including attempts to gain access to the network (in our simple example above, imagine if the same user account tried to ssh into machines it doesn’t have network access to).

    As of this writing, EDR and XDR are using machine learning (ML) to perform faster processing of all the data they are seeing, and to limit false positives while raising critical alerts up to human operators. At this point in the ongoing feud between attackers and security personnel, I’ll go so far as to call it state-of-the-art. For now. Other attack vectors and XDR-defeating attacks will no doubt come along, and will have to be answered, but for now, if you have a publicly exposed network, it is the best you can get. Vendors have moved both EDR and XDR analysis to the cloud, ostensibly to improve analysis. It does reduce the amount of maintenance customers must perform, but cloud usage comes with an operational pricetag that prospects should understand before signing on the dotted line. Most mid-sized or larger organizations don’t have a storage or processing power shortage, so operational efficiency is what you are really paying for, in most cases. Make sure it’s worth the cost, and you have a plan if you lose access to that ML engine in the cloud.

    Meanwhile, keep kicking rear. Mark each day with, “At least we’re not SolarWinds,” and, remember: you’re doing your best to protect the org in a dynamic and hostile environment. Celebrate each day without a breach as a success – because someone did try.

  • ARMO Aims to Simplify Microservices Security

    ARMO Aims to Simplify Microservices Security

    ARMO this week emerged from stealth to launch a platform to secure cloud-native workloads and improve visibility. The ARMO Workload Fabric technology attaches code within the memory invoked by a microservice to enable cybersecurity policies to be applied via a cloud service.

    Company CEO Shauli Rozen said the ARMO Workload Fabric is designed to enable IT organizations to implement a zero-trust architecture more easily within the context of a DevSecOps workflow.

    Fresh from raising $4.5 million in seed funding, Rozen said ARMO’s approach eliminates the need to deploy and manage agent software, container sidecars or runtime application self-protection (RASP) software to enforce security policies across what inevitably will become thousands of microservices distributed across an enterprise IT environment.

    That leaner approach then allows for a centralized management platform that can be deployed on a cloud or on-premises IT environment to apply policies that restrict which microservices can communicate with one another, Rozen said. The approach would ensure that only microservices developed using a continuous integration/continuous delivery (CI/CD) platform are allowed to communicate with other microservices, Rozen said.

    Integration with multiple CI/CD platforms is already provided, added Rozen.

    That approach allows policies to be applied to microservices regardless of how they are constructed, Rozen said. That capability is critical, because developers are building microservices using everything from Python and Java to containers, he said. Many of those microservices are also frequently replaced, Rozen said, which can make updating any associated agent software a significant DevOps challenge. Given all the existing dependencies between microservices, overall application environment security is only as strong as the proverbial weakest link. The ARMO Workload Fabric enables developers to add a small amount of code to implement security policies each time a microservice is rolled out into a production environment.

    As part of an effort to make it simpler for IT organizations to apply those policies, ARMO provides a pre-built set of policies that organizations can immediately apply, in addition to creating their own polices over time, Rozen said. In many cases, IT teams simply don’t have the time or expertise required to build those policies, Rozen added.

    Microservices are being built and deployed at such a breakneck pace that it’s nearly impossible for cybersecurity teams to keep up. The ARMO Workload Fabric provides cybersecurity teams a means to centrally manage security policies that would otherwise be implemented as code by developers. It provides a level of observability for how those cybersecurity policies are being implemented across microservices that typically have a lot of dependencies on one another, Rozen said.

    Most organizations today recognize there is a clear need to shift responsibility for application security further left toward developers. The challenge is finding a practical way to achieve that goal, and in a way that doesn’t adversely impact the rate at which applications are being developed. The key to achieving that goal is finding a way to apply microservice security polices that causes the least amount of friction possible to existing DevOps workflows.

  • Thread is the Future of Wireless Mesh

    Thread is the Future of Wireless Mesh

    Over the last decade or so, interest in IoT technology and connecting devices to one another, and to the internet, has increased. Of course, one of the key elements necessary to connect devices is wireless communication. There are several wireless interfaces, such as cellular, Wi-Fi, Bluetooth, ZigBee, LoRa etc., that are prominently used in different industries to make these connections. However, choosing the right wireless technology is vital for the success of any product. One should consider several factors before zeroing in on the right wireless technology for your goals. Some of the factors to consider include:

    • Wireless range/ coverage
    • Throughput
    • Power consumption
    • Scalability
    • Security
    • Ease of provisioning

    Selecting the right technology to get the best results and satisfy all your requirements is a challenge, and what’s “right” may vary depending on use case. For instance, cellular technology is often preferred for a mobile device used in logistics applications, as it has excellent coverage. However, cellular technology is power-hungry; it would be difficult for the battery-powered device to operate for long periods of time. Similarly, LoRa, with a wide wireless range and low power consumption, is an excellent choice for applications such as smart metering. But it has a relatively low data throughput, and therefore may not be the ideal choice for certain industrial applications.

    What is Thread?

    One of the recent entrants to the wireless communication space is Thread. Thread is an IPv6-based, low-power, open source, mesh networking protocol for connected devices, backed by Nest Labs (a subsidiary of Google) and other industry bigwigs. Like ZigBee, it uses IEEE 802.15.4 wireless mesh protocol, but, being internet protocol (IP)-based means a Thread network can seamlessly connect to the internet without needing a translator or a gateway in between. Thread operates on the 2.4GHz ISM radio band, the same as ZigBee, and offers a throughput of 250 kbits/s with a typical range of about 30 meters. It employs spread-spectrum techniques to provide immunity to interference. Thread’s low power consumption means that a coin cell could power it for almost two years.

    Thread as a Mesh Network

    As a mesh network, Thread can have several hundred devices communicating with each other and the cloud. A typical Thread network would consist of an endpoint device, router node and a border router. A typical endpoint would be a battery-powered device that communicates with a parent router. A router node would receive packets from devices on the network and forward them to the rest of the network. The border router is a device that facilitates communication between a Thread network and a non-Thread network, such as Wi-Fi or Ethernet, by forwarding packets.

    Benefits of Thread

    Because Thread is a self-healing mesh network, it offers many benefits. One is avoidance of a single point of failure. That is, if any router in the network fails, another router automatically takes its place. Unlike ZigBee, for example, Thread devices can be linked to multiple border routers, making the network more reliable. Another advantage is that, being mesh, the Thread network is highly scalable. Each Thread network can scale to hundreds of devices. Thread also benefits from being built on IPv6 to take advantage of end-to-end routing and addressability. Any two IPv6 endpoints, whether on the same Thread mesh or across networks, can communicate, end-to-end, with easy and well-understood internet routing mechanisms moving packets from one endpoint to the other.

    One of the biggest benefits of Thread is that it can provide a high level of security. Security breaches associated with IoT and connected devices are on the rise, and are a major barrier to legacy device connectivity. All devices in a Thread network are automatically authenticated and communication is encrypted. Thread networks use a secure, financial-class encryption and the technology has plugged the obvious security loopholes found in other wireless protocols.

    An IoT device should be easy to deploy in the field, which is another factor in selecting the right wireless technology. Thread devices can be easily set up using a smartphone or a tablet. Users can securely connect devices to each other, and to the cloud, for easy control and access from anywhere.

    Thread is built on 6LoWPAN, which is the same radio protocols as that of ZigBee; an IEEE 802.15.4-based specification for high-level communication used to create personal area networks with digital radios. It’s possible that, with just a software upgrade, an existing ZigBee module can be converted to a Thread module. For legacy ZigBee users, it would be relatively easy to migrate to Thread technology. Availability of OpenThread, an open-source implementation of Thread, is likely to accelerate the development of products that leverage Thread. However, the limited availability of off-the-shelf border routers, and the use of less preferred mesh topology, is a challenge for its adoption into IoT devices.

    The Future of Service Mesh

    Thread has great potential, and can be considered a very good alternative to existing wireless communications options with the added benefit of Wi-Fi-like features. Because it’s open source and backed by large semiconductor manufacturers and technology heavyweights, Thread technology is poised to gain substantial momentum over the next few years. It may eventually emerge as the primary choice for medium throughput, low power IoT applications.

  • Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri today unveiled a platform-as-a-service (PaaS) environment through which developers can embed geospatial capabilities into their applications by making an application programming interface (API) call to a cloud service.

    Euan Cameron, CTO for developer technology at Esri, said the ArcGIS Platform will make it simpler for developers to incorporate mapping capabilities enabled by a geographic information system (GIS) system with, for example, a mobile application. The entire ArcGIS software stack can be accessed by those applications by making an API call. Previously, IT teams would have to stand up the entire Esri platform on their own to provide development teams with access to the Esri geospatial platform.

    The PaaS environment also makes it possible for developers to access professional-grade geospatial content that can be plugged directly into their applications, Cameron said.

    Geospatial platforms gained prominence with the popularity of mobile applications that require mapping capabilities. With the expansion of 5G wireless networks, the number of applications that require similar capabilities will continue to grow, Cameron said. A PaaS environment that abstracts the complexity of managing a geospatial platform behind a set of APIs will make it easier to build those applications at scale, Cameron said.

    There are, of course, other approaches to making geospatial databases available as a service. However, Cameron said Esri has long history of providing these capabilities alongside content it curates across a wide range of consumer and business applications. Those capabilities are now an API call away from any application, Cameron said.

    Of course, DevOps teams will need to integrate a PaaS environment that can be invoked as a cloud service within their overall workflow. Esri is committing to making its PaaS offering available on a global network of data centers to minimize latency for applications making API calls to its platform.

    These days, it’s hard to imagine an application that doesn’t require at least some degree of geospatial capabilities. Time and place have become critical elements of any application experience. The total cost of providing those capabilities drops considerably when the geospatial platform required to enable them is managed by its provider. In fact, as application development continues to evolve, DevOps teams often find themselves orchestrating a broad range of API calls to external services. Each one of those calls is simple enough, but over time, the sheer number becomes challenging to manage. Nor is the quality of the APIs surfaced by each service always of the same quality.

    Regardless of how geospatial capabilities are integrated into an application, the days when dedicated teams managed complex GIS platforms may finally be coming to an end.