devopsy.kinsta.cloud

Tag: API

  • Top 6 Challenges of API Testing

    Top 6 Challenges of API Testing

    Testing teams face several unique challenges when testing application programming interface (API) implementations. API testing is part of the integration testing process and concerns the communication between two systems—one of which your staff likely has no control over.

    Below you’ll find the following six common challenges when testing APIs and our recommended solutions.

    Initial Setup of API Testing

    Manual testing helps confirm whether something works. Automated testing is necessary with APIs to gauge how well they perform under pressure. Getting the testing infrastructure up and running is often one of the most challenging parts of the process, not because it is particularly difficult, but because it can be a substantial motivation-killer. Once you manage to motivate your team to get through the process, however, it pays off over the long-term.

    Solution: API testing should start in the design phase—how is the API going to be tested? Ensure interval checking of your APIs for 100 percent uptime.

    Updating the Schema of API Testing

    The schema—in other words, the data formatting that handles requests and responses for the API—needs to be maintained throughout the testing process. Any updates to the program that create additional parameters for the API calls need to be reflected in the schema configuration.

    Solution: In today’s API economy, having an ever-changing API helps facilitate the demand. However, there can be downtime caused by those changes. One way to avoid that is to thoroughly test the API in beta and alpha environments. The chances of issues decrease to 90 percent when testing in these environments.

    Testing Parameter Combinations

    APIs handle communication between systems by assigning data values to parameters and passing those parameters through data requests. It’s necessary to test all possible parameter request combinations in the API to test for problems pertaining to specific configurations. A larger project could end up assigning two different values to the same parameter, or create instances where numerical values appear when text values should be. Adding an additional parameter exponentially increases the number of possible combinations.

    Solution: We’ve learned from our customers that having release candidates are important. For example, picking one or two applications to utilize the API on and release it to just those applications. Pick applications that aren’t critical to daily operations. This way you’re able to see how the API is being utilized and if there are any configurational changes that need to be made to have a general availability (GA) release.

    Sequencing the API Calls

    In many cases, API calls need to appear in a specific order to work correctly. This creates a sequencing challenge for the testing team. For example, if a call to return a user’s profile information goes through before the profile is created, the request will return an error. Alternatively, a call to create a map needs to run prior to placing location pins on the map to work correctly. This process can get increasingly difficult when working with multiple-threaded applications.

    Solution: This relates to the point above of having a release candidate to help in managing and seeing what the sequencing of the API calls are. We recommend making a flowchart to visualize the API calls. This will help developers build API calls and integrate them faster without causing issues.

    Validating Parameters

    Testing teams may find validating the parameters sent through API requests challenging as well. The sheer number of parameters and use cases for those parameters can make it a daunting task. The team needs to make sure all parameter data uses the correct string or numerical data type, fits within length restrictions, fits within a designated value range and passes other validation criteria. For example, U.S. phone numbers should appear in a 10-digit format, and returning a 5-digit zip code should trigger an invalidation error.

    Solution: This can be avoided by having continuous synthetic API monitoring to catch the problem early on. Moreover, it should be combined with an APM solution to get an overall 360-degree view. Validating parameters is one of the most important things. It should show you how fast you’re serving those parameters. If making those calls has significant impacts on your system, implementing synthetic and APM solutions will ensure you catch the problem early on.

    Tracking System Integration

    The final challenge is making sure the API testing system is working correctly with the data tracking system. This is necessary to bring back correct responses on whether a call is working correctly. It’s also used to passively monitor API performance. Since this step can come late in the process, the team may be too fatigued to give it the attention it needs.

    Solution: Think about your application in the design phase and how it will integrate with other systems. Different applications have different requirements that need to be met. Make sure you aren’t causing applications to fail by testing in parallel with critical integration systems. This can be accomplished by implementing and including load testing in your continuous delivery.

    API testing is an essential part of application development in the modern business environment.

    About the Author / Sven Hammar

    Sven Hammar is co-founder and Chief Strategy Officer of Apica, a provider of technology for testing, monitoring, and optimizing the performance of cloud and mobile applications. Mr. Hammar has more than a decade of experience and expertise in web performance and web optimization, e-commerce, cloud services, IT entrepreneurship and the Internet. He is also a serial entrepreneur who has founded several successful IT companies over the years. Connect with him on LinkedIn.

  • The Postman Delivers More

    The Postman Delivers More

    Most of us use Postman during API development. The company claims 3 million users, and as one of them, that number doesn’t raise my eyebrows any. But if you are like me, you’ve figured out collections, how to back up your data and perhaps looked at tests, but not done much more. As a tool for API development, Postman is powerful and useful, but that means many of us don’t look very far beyond how quick and easy it is to set up an out-of-browser test environment to evaluate request/response.

    We use collections to separate projects, but really only as a way to group calls together and keep a single copy of each call close to hand while the history list scrolls through multiple copies.

    But for DevOps, there’s more. And they’ve just added to it again.

    Packing in the Features

    Groups can be used for grouping calls with tests, for example, and a command line tool can perform automated testing. If, like us, you use Postman to test as the API is developed, and use groups to keep those calls pulled together in one place, then testing from the source that already contains your entire API makes sense.

    And as of this week, Postman also includes the server side. Postman Mock service allows you to mock up the API calls and specify a valid return value. That means client-side developers can use Postman Mock for testing their app/page, while server-side developers are using the original Post

    man to develop the APIs that Mock emulates and testing is running tests from the real-world APIs that already are in Postman for development purposes.

     

    Dev, DevOps, Testing and Ops: Something for Everyone

    So a quick diagram shows that the entire development process has a bit of Postman in it if that’s your tool of choice:

    While all assist with agile development, for DevOps, the pieces that are the most beneficial are Test combined with Groups and the new Mock service. As long as the Mock service is configured for a group of calls, test can call them and the logged output can reflect that the test succeeded but ran through the mock service. Once the service is completed and the group is directed to point at the server, testing will run tests against the real API. Using Newman, the command line tool, these tests then can be integrated with your build toolset.

    The Mock service can take imports from SOAPui, if you are converting from SOAP calls or use SOAPui for REST and are moving to Postman. I’m told the Postman toolset also supports SOAP calls, but truth in writing, I’ve never even looked to see how that would be done. I’ve used both tools, but never on the same project.

    There’s a Cost, but There’s Also Value

    This next bit sounds a bit salesy, and I try not to do that. But for the price, there aren’t a lot of value-add tools out there that deliver this kind of value. Lori and I are talking about going Pro, as we both use Postman in projects. And considering we’re regular users, I figured if we didn’t know about most of these features, many of you wouldn’t, either.

    Mock is part of Postman’s Pro package, along with sharable team collections, and API documentation tools. That means it will cost you a little bit of money, but if you’re on a team and have been cobbling together a way to share collections, team collections and associated collaboration tools are worth the price—particularly since built-in auditing will show all of the changes made to Postman collection items. That means fixing a change-based error on the Postman side is easier.

    As of this writing, the cost for Postman Pro was $8 per user per month. My guess is sharing groups (or worse, each team member re-creating/maintaining them) costs more than that per month in many cases. Consider that documentation can be generated and shared to a private URL and the fact that Mock service enables parallel development, and $8 sure seems like a steal. Finally, Pro offers API monitoring, so performance and uptime can be tracked to better adjust to the realities of production. There’s more (such as integrations with some great Dev/Ops/DevOps tools), but I’ll stop.

    Summary

    Design, Development (both client and server, in parallel), Test, Monitoring … as long as you can get it deployed, Postman can help with the rest. Postman Pro has a reasonable price for the functionality it offers, and the introduction of the mock service makes agile development, tight timelines and consistent “start to deployment” testing easier. I’d venture to say it is worth taking a look at. And if you’re developing APIs without it, pop out and get the free version, you’ll quickly find why so many of us use it.

    You can find out more about the various editions of postman on Postman’s Product page.

    — Don Macvittie

  • Red Hat to Acquire API Management Leader 3scale

    Accelerates digital transformation with API driven hybrid-cloud architectures

    RALEIGH, N.C. — —

    Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced that it has signed a definitive agreement to acquire 3scale, a leading provider of application programming interface (API) management technology. By adding 3scale to its existing portfolio, including Red Hat JBoss Middleware, Red Hat OpenShift and Red Hat Mobile Application Platform, Red Hat strengthens its enablement of the API economy with simplified cloud integration and microservices-based architectures.

    3scale complements our existing middleware product portfolio and Red Hat OpenShift by enabling companies to create and publish APIs with tools such as Red Hat JBoss Fuse, and then manage and drive adoption of those APIs once they have been published.

    CRAIG MUZILLASENIOR VICE PRESIDENT, APPLICATION PLATFORMS BUSINESS, RED HAT

    In an era of digital transformation, agile development practices, and hybrid technology footprints, the API economy has become the norm. Forrester has estimated that 40 percent of U.S. companies will have API management solutions in 2020, spending $660 million in that year.1 Managed APIs are becoming strategic in the enterprise because they enable organizations to rapidly deliver new services that are easy to consume yet secure, scalable, and reliable, as well as enabling services (as APIs) to be monetized as products. Emerging architectures that decompose functionality into ever more finely-grained components–”microservices”–driven by mobile, the Internet of Things (IoT), and other trends, have further heightened the need for API management.

    3scale was founded in 2007 with a goal of enabling organizations of all sizes to successfully create, manage, and use APIs in a web-enabled world where APIs became paramount. Today, 3scale offers a hybrid cloud based API management platform, which separates the cloud management layer from the API gateway, providing customers with flexibility, performance, and scale. 3scale provides this API management platform within a self-service model at more than 700 organizations across multiple industries, including Campbell’s Soup; Cartera Commerce; CrunchBase; Johnson Controls; Oxford University Press; SITA; and the University of California, Berkeley. 3scale has offices in Barcelona and San Francisco.

    3scale and Red Hat began partnering in early 2015 to deliver a comprehensive platform for API-based application development. The joint solution combined the 3scale API Management Platform with technologies from Red Hat JBoss Middleware, Red Hat OpenShift and Red Hat Mobile Application Platform to provide an API-centric development, deployment, and management offering designed to accelerate application time-to-market. Red Hat JBoss Middleware customers will benefit from the hybrid-cloud capabilities from 3scale for modern architectures. Mobile application development in particular is highly API-centric and 3scale’s platform combined with the Red Hat Mobile Application Platform can lead to development and management simplicity at massive scales.

    Most recently, 3scale introduced a containerized version of their API Gateway for Red Hat OpenShift, enabling users to easily and consistently create applications with microservices distributed across diverse, hybrid environments. The combined power of Red Hat’s container application platform and 3scale’s API management capabilities enables customers to simplify and automate tasks, helping reduce errors while increasing flexibility and control.

    Red Hat has provided enterprises with leading open source platforms for building modern applications, integration and automation solutions. With the addition of 3scale’s API management solutions, and its existing middleware, container application platform, and mobile offerings, Red Hat can further simplify and accelerate customers’ digital strategies and accelerate time-to-market for API initiatives, and enable enterprises to innovate faster, in a smarter way.

    The acquisition is expected to have no material impact to Red Hat’s revenue for the second fiscal quarter ending August 31, 2016 (the “second quarter”), or its fiscal year ending Feb. 28, 2017 (“fiscal 2017”). Management expects GAAP operating expense to increase by approximately $3 million, or ($0.01) per share, in the second quarter and approximately $7 million, or ($0.03) per share, for fiscal 2017 as a result of the transaction. Management expects that non-GAAP operating expense will increase by approximately $1.5 million, or approximately ($0.01) per share, in the second quarter and approximately $5 million, or approximately ($0.03) per share, for fiscal 2017 as a result of the transaction. Red Hat calculates non-GAAP operating expense by subtracting from GAAP operating expense the estimated impact of non-cash share-based compensation expense, which is expected to increase by approximately $0.8 million for the second quarter, amortization of intangible assets, which is expected to increase by approximately $0.2 million for each of the remaining quarters in fiscal 2017, and transaction costs related to business combinations, which are expected to be less than $1 million in the second quarter. For Red Hat’s full forecast, including the expected impact of the transaction on GAAP and non-GAAP operating margin and GAAP and non-GAAP earnings per share, refer to the guidance provided in its June 22, 2016 earnings press release.

    The transaction is expected to close in June 2016, subject to customary closing conditions.

    Supporting Quotes
    Craig Muzilla, senior vice president, Application Platforms Business, Red Hat
    “APIs play an important role in helping to accelerate innovation and business growth in the digital economy. With digital transformation initiatives identified as a top priority for organizations today, API management has become the foundation for exposing those APIs for better use, performance, and value creation. 3scale complements our existing middleware product portfolio and Red Hat OpenShift by enabling companies to create and publish APIs with tools such as Red Hat JBoss Fuse, and then manage and drive adoption of those APIs once they have been published.”

    Steven Willmott, CEO, 3scale
    “We’ve already seen great customer success combining Red Hat’s excellent middleware platform with 3scale API management, and we see tremendous opportunity to benefit customers even more as they expand their API, middleware and microservices plans. We see this as a natural extension of our relationship, and we’re excited to be joining an organization with such a strong commitment to open standards, open source and spreading the benefits of technology.”

     

    1 Forrester Research, “Sizing The Market For API Management Solutions,” April 2, 2015.

    ABOUT RED HAT

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to provide reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As a connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more athttp://www.redhat.com.

    FORWARD-LOOKING STATEMENTS

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the ability of the Company to compete effectively; the integration of acquisitions and the ability to market successfully acquired technologies and products; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; delays or reductions in information technology spending; the effects of industry consolidation; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Annual Report on Form 10-K (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations”. In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    ###

    Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, and OpenShift are trademarks or registered trademarks of Red Hat, Inc.or its subsidiaries in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

  • DevOps and the Challenge with Services

    DevOps and the Challenge with Services

    At RackN, we’ve been working for years to make DevOps portable across platforms. For us, that means the ability to move between clouds and from cloud to metal. Of the several challenges to portability—composability, API heterogeneity, sequence, cross-system dependencies—making configuration management tools work with services has been particularly important, as significant parts of building systems rely on services that are not directly configurable.

    Let’s look at DNS as an example. Whenever we configure services on a node, there are DNS implications. If we bring up a web server, we want to use a logical name for the node. If it’s a secure web server, that name should match our certificate. If we want to make that service discoverable, we likely want to add a logical name for that node, such as “clustermanager6.example.com” or similar. If you include names for BMC and rack location—not to mention IPv6 naming—it’s easy to image nodes with 10 names. Even cloud nodes have similar issues. That’s a lot of entries to manage!

    The problem with all those DNS names, and similar services, is that they are NOT configurable from the node. They are services with APIs that require restricted authorization.

    Services and Automation

    DNS is just one simple example.  System-level DevOps has many places where the configuration workflow needs to include external service actions. In cloud environments, generally that means either writing pre- or post-configuration steps that talk to the specific cloud API or using one of the cloud-specific template files. In physical environments, generally that means a lot of added manual steps or tightly constraining automation to inventory map files. No matter what, nodes don’t own DNS configuration—it’s a node external service with the API elements that are site specific.

    All of these approaches make DevOps brittle and site-locked. Five years ago that was okay, when choices were more limited and scripts were hand-crafted by DevOps artisans. Today, we need our automation to be robust, portable and transparent.

    We realized system automation needed to treat services interactions as equal to configuration. That means when we’re working on provisioning, we make sure service steps can be woven into the sequence of configuration steps. They must not be assumed correct or delegated to pre- or post-conditions because that makes it impossible to test and re-create working environments.

    What can you do? We’ve found service registration tools (we like Consul.io) are essential and relatively easy to implement to help track services that we manage or proxy. More broadly, we’ve been working in the open on Digital Rebar to blend configuration and services into a single workflow.

    The first step is to re-examine your configuration management scripts (and their prerequisites) for hidden service API interactions. Exposing those external dependencies will help you improve your automation repeatability and portability.

  • Continuous Testing: What exactly is it?

    Continuous Testing: What exactly is it?

    ***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

    The aptly named DevOps practice of Continuous Testing synchronizes Testing/QA with Dev and Ops processes optimized to achieve business and development goals.

    A few years ago when Agile was all the rage, lightning-fast Dev sprints left the Ops and QA personnel playing catch-up due to inadequate and sluggish testing practices with minimal coverage across frequent builds.

    The widespread culture of Agile development has accelerated development while software testing still lags behind, forcing organizations to cut corners in QA or slow down Dev processes entirely.

    Instead of speeding up the conveyor belt beyond control or slowing down development to kill efficiencies, Continuous Testing in DevOps encourages a systematic approach toward process improvement.

    Continuous Testing goes beyond automation and encompasses all practices — including tooling and cultural change — that help mitigate risks before progressing to subsequent Software Development Lifecycle stages.

    Continuous testing and Automation

    The approach to Continuous Testing can vary and follow diverse pathways to ensure the best user experience is delivered, free of defects.

    It’s barely viable to repeat all tests every time a new feature is added, so the Continuous Testing strategy fosters a company-wide cultural change to achieve four capabilities: Test early, test faster, test often and automate.

    End-to-end test automation practices are intended to integrate QA into existing fast-paced Dev and Ops processes as a means to create continuity while maintaining faster development cycles.

    It’s important to understand the role of automation in Continuous Testing. Automation alone does not enable continuity in testing, but it helps provide a qualitative assessment of risk and practice actionable tasks to mitigate these risks throughout the SDLC.

    In essence, automated testing constitutes the detection process for software issues and defect prevention, whereas Continuous Testing addresses the wider challenge of improving the effectiveness of these detection sensors.

    What does Continuous Testing Look Like

    This example demonstrates how collaboration, automation and tooling enable end-to-end testing that’s performed faster, more often and better aligned with Agile Dev and Ops practices.

    Continuous Testing starts within development processes as Devs use open source tools such as Selenium to test the functionality of their code.

    Tools such as GitHub or other internal repositories can then be used to store tests and version together with the software code. DevOps teams can use the same tests to integrate frequent builds of the software with the Load Impact API.

    Once the code reaches preproduction, dedicated QA teams can use these tests by modifying dynamic test parameters as appropriate. In the production environment, Ops can reuse these tests for acceptance testing and ongoing post production monitoring.

    Once the application goes live, integration with existing APM tools help keep tabs on server-side app metrics.

    Continuous Testing in this example is broken up into at least four environments: Development environment, Continuous Integration environment, QA Pre-production and Performance testing environment, and the Staging environment. Additional post-live monitoring further enable end-to-end continuous testing.

    Key Elements of Continuous Testing

    Parasoft, a global software solutions company, is one of the great thought leaders in DevOps and Continuous Testing. The company has laid out some key elements of the process in a fantastic e-book, and they’re definitely worth sharing here:

    Risk Assessment: Covers risk mitigation tasks, technical debt, quality assessment and test coverage optimization to ensure the build is ready to progress toward next SDLC stage.

    Policy Analysis: Ensure all processes align with the organization’s evolving business and compliance demands. Primary objectives include:

    • Identifying trends associated with injection of dangerous patterns within the code
    • Augmenting defect prevention practices for high risk areas
    • Isolating risk in target areas

    Requirements Traceability: Ensure true requirements are met and rework is not required. An object assessment to identify which requirements are at risk, working as expected or require further validation.

    Advanced Analysis: Using automation in areas such as static code analysis, change impact analysis and scope assessment/prioritization to prevent defects in the first place and accomplishing more within each iteration.

    Test Optimization: Ensure tests yield accurate outcomes and provide actionable findings. Aspects include Test Data Management, Test Optimization Management and Test Maintenance.

    Service Virtualization: Early, frequent and everywhere testing requires access to real-world testing environments. Service visualization enables access to the virtual form of the required testing stages, cutting the waste time to test environment setup and availability.

    An effective Continuous Testing strategy incorporates all of these elements and forces an organization-wide cultural change to synchronize Dev, Ops and QA/Testing as part of the true DevOps philosophy.

  • The Internet of APIs

    The Internet of APIs

    The Internet moves at the speed of light. Not only that, but the terminology used when describing The Internet seems to change with the tides. One of the newest phrases to start making the rounds is “The Internet of APIs.” In an attempt to understand exactly what it is, I went looking for a definition and was unable to find anything at all. As such, it’s time to put a definition out there.

    There are two important words in the phrase: “Internet” and “API”. Let’s start with the last word first and work backwards. What exactly is an API? Luckily, the definition of API is pretty settled. For our purposes, I like the definition given to us by API Evangelist:

    An API, or Application Programming Interface, at its most fundamental level, is how software applications talk to each other using the Internet. An API allows you to open up data and other digital resources, to public developers, businesses, or even between departments and locations within a company. APIs are increasingly the way in which companies exchange data, services and complex resources, both internally, externally with partners, and openly with the public.

    And while we’re at it, let’s look at the popular definition of “Internet” given to us by Webopedia:

    The Internet is a global network connecting millions of computers. More than 100 countries are linked into exchanges of data, news and opinions.

    So we’re narrowing down on a definition of The Internet of APIs. But we’re not quite there yet. Let’s look back at recent history to see if we can clarify things a little bit. The modern-day web API has been around since Salesforce introduced it’s API at the turn of the century. In the year 2000, they introduced an XML-based API that kicked off the web services API era. And while there were a few other web services APIs that came out afterwards (including eBay and AWS); but things didn’t really start getting serious until Flickr launched their API in 2004. The social network revolution, sparked by companies like Friendster, MySpace and Twitter, brought about a real need to securely exchange information between multiple applications. So when Facebook and Twitter announced their own APIs in 2006, that was when the usage of APIs grew to include identity management in addition to the exchange of data it had become known for.

    And then came smartphones. APIs exploded in popularity once the smartphone industry took over the continent thanks to Palm and Blackberry; then came iOS and Android. Why the popularity explosion? Well, applications needed to be made for these new (popular) form factors. However, these new form factors had very specific requirements around data usage, drastically different screen sizes than application developers were traditionally used to, along with previously unseen device capabilities. Add to that the fact that mobile applications needed to figure out a way to share data with each other securely and a perfect storm of needs presented itself.

    While all of this was going on, the wireless capabilities available to the consumer also changed. In the year 1999, one year before Salesforce released their web services API, 802.11a and 802.11b hit the market. WiFi was still a growing technology, but the introduction of 802.11a and 802.11b changed everything. The prior iteration of 802.11 had a transfer rate of 2 Mbps; while a allowed for short range speed of 54 Mbps and b allowed for longer range speed of 11 Mbps. The cost of b was also a lot lower than a.

    Also in 1999, the first full Internet service available on a phone was launched in Japan by NTT Docomo. This was during the days of 2G networks. In the US, around the same time, cell phones became affordable to everyday consumers. It was a time of incredible growth in the wireless industry and over the following years, cellular networks were stretched to their limits.

    This is the environment that led to the growth of the web service API. There were a few things that were extremely important to the upcoming boom:

    1. A speed boost in wireless networking was required; and
    2. Wireless networking hardware needed to get into the hands of more people; and
    3. The cost of wireless networking hardware needed to drop; and
    4. Cell phones needed to get in the hands of more consumers; and
    5. Internet service needed to hit the cell phone.

    Add all of that to the growth of social networking and identity management via API, and a perfect storm of circumstances presented themselves. More and more APIs were built utilizing a person’s identity for personalization and security.

    Thus the Internet of APIs was born.

    So, based off of the existing definitions as well as recent history, what exactly is “The Internet of APIs”? The Internet of APIs is:

    A global network of structured data, digital resources and commands accessible via a growing interface that allows applications and devices to exchange information using any and all communications protocols available.

    Since the creation of the ARPANET (arguably, the Internet’s predecessor) packet-switching networks have been utilized as an efficient and reliable way to exchange data. So what’s different about the Internet of APIs since at its core it’s about exchanging data? The main difference lies in the fact that the data provided by the Internet of APIs is data with structure. It’s data that is being shifted around and meant to be consumed in ways that may not possibly have even been foreseen by the creator(s) of the data. The Internet of APIs allows data that may have been designed for one thing to be used for something completely different; thus facilitating the connection of two completely different applications in ways sometimes unimagined.

    The Internet of APIs is the underlying foundation to the Internet of Things. Without the capability for connected devices to personalize their usage according to the individual, as well as share data, the Internet of Things could not exist. Without the improvements in specifications in both wireless and cellular hardware, the Internet of Things could not exist.

    The Internet of Things is powered by the Internet of APIs; and as the Internet of APIs grows in scope and capability, the same will happen to the Internet of Things. Without regularly updated data and personalization, a hardware device is dumb. A thermostat is just a thermostat without the underlying API. But with the API, a thermostat becomes a Nest. Without an API, a light bulb is just a light bulb. But with the API, a light bulb becomes a Philips Hue light bulb. Without the Internet of APIs, a person walks in to their home, walks in to their living room, flicks a light switch and turns their heat up. With the Internet of APIs, a person walks in to a warm, well lit home because their thermostat turned on five minutes before they got home and their lights turned on one minute before they walked through the door.

    Data and personalization: that is the power of the Internet of APIs.

    About the Author/Kurt Collins

    Kurt-Collins-devopsdotcomKurt Collins is Director of Evangelism at built.io (link). Before that, he started his engineering career as an intern at Silicon Graphics (SGI) where he worked on debugging different parts of their UNIX-flavored operating system. Two years ago, Kurt co-founded The Hidden Genius Project along with eight other individuals after they all saw the screaming need to increase the amount of Black men in the technology industry. Mentoring young people interested in the technology industry is a personal passion of his. Today, he continues his work with tech startups and non-profits alike.

  • The Role of a Traditional NOC in the new DevOps World

    The Role of a Traditional NOC in the new DevOps World

    This new question in the devopsy.kinsta.cloud Enterprise DevOps Q&A series comes from a large business, though not what many would recognize as a traditional or legacy enterprise. This organization, like many high-growth businesses, is in a relatively new market segment that only exists due to the rise of cloud computing and digital media. In their business, the network (especially access to and from their public cloud service) is critical to the value they provide their customers.

    So it is no surprise then that, as they contemplate their transformation to an agile environment built on DevOps principles, they are asking me about the role of the Network Operations Center (NOC).

    1. What Role Does a NOC Play in the DevOps World?

    Despite coming from a ‘new tech’ business, this is another of the questions that is typical in a large enterprise. While smaller startups and even many web-scale businesses may have an Application Support team, not many run their own NOC, and even fewer separate out these roles from the rest of the operations team.

    First, some things do not change in a DevOps world. Fundamentally, the NOC is still tasked with maintaining high quality production networks and systems, detecting potential problems as soon as possible, triaging those problems to find root cause, and remediating problems as fast as they can.

    However, the NOC team will gain additional activities and support a broader interlock beyond just the production environment, especially as networking becomes more embedded in application delivery through capabilities like software-defined networks and cloud computing. They will work more closely with teams like app dev, SQA, pre-prod and release; they will provide input to design and development; and they will contribute earlier in the software cycle. This is the logical outcome of a DevOps approach that emphasizes the need to work more collaboratively across the entire end-to-end SDLC.

    So you should consider bringing these network specialists into:

    • development planning, to help architects and engineers to build applications with operable networking by design, including software-defined networks that help make a truly idempotent application
    • testing and QA, so they can provide engineers and SQA teams with tests and analysis that accurately reflect the reality of the prod network, rather than leaving network testing to after production deployment
    • dev/test support (where they may already be acting), to ensure that the environments that dev/test rely on to create new capabilities are just as stable and reliable as the systems they will eventually be deployed to
    • release and deployment, to ensure they have input into determining and defining ‘known good values’ for production monitoring and for problem diagnosis, triage, and escalation – before release, not just after
    • expanding interoperability and self-service, by exposing ‘known-good’ deployment, triage, and (re-)configuration capabilities as automated software-defined processes (or APIs) that dev/test can use without opening a new service ticket
    • a broader role in ensuring the end-to-end quality of the network, alongside traditional operations/infrastructure support as part of a new role commonly referred to as a ‘Site Reliability Engineer’ (SRE)

    Because DevOps is about improving collaboration, remember too that you should also bring dev, test, QA, etc. into the NOC, and even rotate them onto support, so they have an understanding of the core operations of a production network, how their code acts in a real environment, and how their work affects other teams. This will help to build the empathy between teams that is a core tenet of DevOps.

    You may be concerned that asking your NOC to work more upstream is adding a load of work to those teams that they didn’t have before. That may be true, but a significant outcome of Enterprise DevOps in practice is to reduce the ‘busy work’ of such teams, free them up to do more ‘smart work’, and to do it earlier in the software lifecycle.

    For example, recent research has shown that DevOps is correlated with improving the quality of applications (especially before they hit production), reducing the amount of time and effort the NOC team spends on problem detection, triage, and remediation. In fact, in this research, ‘reduction in time spent fixing and maintaining applications’ is one of the strongest outcomes, with an average 21% reduction in this metric.

    Similarly, standardizing on known-good processes, APIs, configurations etc., and enabling other teams to employ self-service and software-defined networking capabilities will allow the NOC team to spend less time on routine responses to things like servicing provisioning and configuration tickets.

    I cannot guarantee they will not be a zero-sum game, especially in the short-term, but over time a DevOps approach should actually spare workload from the NOC team, freeing them up to ‘shift left,’ moving their talents earlier in the SDLC, as they communicate, collaborate, and integrate more closely with upstream teams like dev, test and QA.