devopsy.kinsta.cloud

Tag: API

  • Functional Programming: Island of Misfit Functional Programming

    Functional Programming: Island of Misfit Functional Programming

    The age of functional programming is dawning. The hype cycle has heated up, and IT departments are getting both real and perceived benefits out of the idea that a function runs on demand only.

    For some, the benefits are very real. Bursty processing, or things that are frequent and quickly resolved, see a benefit from being implemented on functional architectures, and the cost of functional architectures is arguably far better than the cost of cloud instances. I say “arguably” because you can always cram more onto an underused cloud instance, but you pay as you go—even more literally for functional programming, so additions each have an incremental cost. But it is incremental, and you have the power to choose whether functional is right for any given bit of the architecture.

    So why the title? Remember The Island of Misfit Toys from the much-beloved Christmas story, “Rudolph the Red Nosed Reindeer”? They were all just a little off. In a world flooded with perfectly good toys, they were left unattended and unwanted.

    That is a risk functional runs in the long run, also. The idea that you can pop a function out there, configure the access point (almost ubiquitously a web application firewall entry point, but things change so we’ll stick with the generic “entry point”), and start sending requests is great. The fact that you only pay for that bit of time when your request is actually being serviced is great, too.

    But this ideas assumes security is baked in at the functional level. If you are deploying this function anywhere with a public IP, it assumes hardcore security is baked in.

    And failure to have that security baked in is the first reason you might have a misfit toy.

    By definition, functional programming-based systems are complex systems. They are the ultimate evolution of microservices. They will suffer all of the headaches and heartaches associated with SOA and add on the issues with REST versioning, etc. There will be 50 or 500 functions, each clipping along and doing its thing, composed to make a single application (in a purist world, composed in a functional programming app).

    Some of these functions will become outdated and unused. You can’t leave them laying around, waiting to be abused. Indeed, a new form of financial attack might be to look for just such abandoned toys and start calling them repeatedly and rapidly.

    Imagine coming in one day and having Finance ask you why your bill at functional provider X tripled in the last month, only to find a function you left hanging around was being called for no good reason?

    But the complexity inherent in lots of small bits of code, each doing a specific task, pretty much guarantees there will be cruft left lying around unless you are very careful.

    And that, my friends, is (finally, I know) the point of this blog. Our monitoring tools today lean toward watching the performance of the application, but you need more than that before you go all-in on functional programming. You need build tools that can tell you when a given function is no longer called—from anywhere. That is a tall order which none of the previous distributed methodologies has managed to master, but it is more important in a world where you have functions sitting in various public clouds with public-facing IP addresses.

    There also needs to be a definitive source code scanner. Those are slowly getting better, but imagine if a library the build system pulls in and uses for 20 or 30 different functional programming microbits becomes compromised? We’ve seen enough instances of ignoring the problem is begging to be a victim, so scanning on build is more important with more systems using external libraries. Or more accurately, with external libraries being pulled into more microservices. There are companies/service providers that will validate your external dependencies and only let you load open source libraries they have certified as safe. I’ve never used one, but they’re worth looking into.

    A list of entry points and places they are accessed from is useful for internal-only applications. You can’t do that with a publicly exposed REST API that anyone can call, of course. I’m a developer and a D&D player, so I’ll use that example: Wizards/Hasbro cannot control where this API is being called from. The same is true for any web services APIs that exist to give others access. But internal APIs that are an integral part of internal systems and not called externally? Those you need an automated way to find references to them in internal source and keep a count. Much like garbage collection, you’ll want to take down ones whose count reaches zero.

    The thing is that in many ways functional programming reduces operational complexity. It certainly reduces operational overhead. But that complexity is replaced with a different kind of operational complexity; maintenance becomes a bigger issue, and the already occurring breakup of code into smaller chunks increases, bringing cross-reference complexity along with it.

    Keep that in mind. You will have orphaned functions, you will have security concerns, you will have changed operational complexity. Plan for these things from day one. They are not at all deal breakers, and the benefits of functional are already clear in certain verticals with more general benefits being discovered as I type. But they’re the new problems that will require answers in this new architecture.

    So, build in oversight and tools from the beginning and go see how functional programming could benefit your project. At this time, it isn’t the answer to every problem, but—like most cool new IT things—it is another tool to have at hand when solving problems for the business.

    And don’t let your functional programming microservices end up on the Island of Misfit Functional Programming.

    — Don Macvittie

  • The Executive’s Guide to Microservices Chapter 3: Choosing A Starting Point

    The Executive’s Guide to Microservices Chapter 3: Choosing A Starting Point

    In the previous chapter, Steve had been asked to provide a comparison of costs and resources needed to migrate to a commercial system versus modernize the current system. He works with Stacey, head of development, who comes up with a modernization plan that includes certain changes that the team will implement to limit downtime.

    Steve has discussed Stacey’s plan with the business, which agreed with the approach toward modernization of the supply-chain system. The business particularly likes the idea that in the future the reduced fragility of the system might mean its IT teams can introduce ongoing improvements even through the holiday season, rather than having to freeze all systems development for a period of four months.

    Now Steve and team are challenged with where to start.

    The team has decided that any changes will require decomposition of the existing monolithic design. The approach to date had been to address requirements functionally, which meant that every time the business requested changes to the system, the code was changed to support those requirements by adding specialized logic to various modules.

    Unfortunately, this approach has resulted in significant amount of technical debt. Each compounded change introduced conditional logic to support prior requirements. Moreover, each new change had the potential to break prior changes, so time-consuming impact analyses had to be done before any changes could be made.

    Steve and team want to decompose the system into a set of microservices that closely resemble the business function they support. Moreover, they want to segregate the specialized business logic into modules that consume the generic business services.

    Obviously, this is a long-term strategy, so Steve and team need to choose how to approach incrementally to enable them to make major strides before this year’s systems freeze. Given the proximity to the holiday buying season and the availability of resources, Steve and team will need to choose wisely which microservices they will create. Moreover, Steve and team know they will be limited by the level of entanglement within the existing code.

    After an initial analysis Stacey’s team determines that the costliest issues stem from the logic to support multichannel customer engagement. That part of the system integrates custom logic with some off-the-shelf ecommerce products. During the holiday season, customer support calls increase in volume and each call can last five to 50 minutes. The large variation is often caused by the inability of the system to address changes in a particular channel post order-placement. For example, if the customer wants to add a gift receipt or wrapping after the order is placed, it must be dealt with out of band. This means that the business has had to add support people during the holiday season just to deal with these issues.

    Stacey and team also believe they can easily isolate the logic for multichannel support within the existing code base and decompose into a set of microservices. The team decide that the existing customer records system must stay as is for the time being, but they can create a new API to more easily access that data from the new microservices. Stacey calls these macroservices.

    The team will create a set of microservices to support the web channel and a set to support the distributor channel, since these each have very different requirements. The current system combines the logic to support both of these in one module today. Since microservices are supposed to be focused on doing one thing well, the team have decided on the following bounded contexts: order creation, order execution (payment), order fulfillment and returns.

    Steve asks Stacey, “Why not just have an order service?”

    Stacey replies, “That is one approach, but we would call that a miniservice as it manages all aspects of orders. However, our goal is to allow parts of the system to change over time with minimal testing and maintenance required. A microservice change should not have broad system implications. Changing the order miniservice could mean that an entire channel could be impacted. With this approach we could change any of these supporting order processes without impacting the entire order function within the company.”

    Steve thanks Stacey for her answer and tells her he has a much better understanding now for what the team is trying to achieve.

    — JP Morgenthal

  • 7 Principles for Using Microservices to Build an API That Lasts

    7 Principles for Using Microservices to Build an API That Lasts

     

    SparkPost launched the first beta version of our cloud-based email delivery service three years ago. At its introduction, a handful of customers sent a few million emails a month. Now, our API is used by tens of thousands of customers—including Pinterest, Zillow, and Intercom—to send more than 15 billion emails a month. That dramatic growth demonstrates how rapidly our business pivoted from providing on-premises email infrastructure to operating as a fully cloud-based email delivery service.

    It’s a great business story. But how did we manage change at that scale with regard to technology and development management? In this article, I’ll review several of the choices and best practices that have helped us to not simply manage this pace of change, but actually to thrive from it.

    REST Is Best: Be Practical, Not Pedantic

    From the start, we took an “API first” approach. Our email API is our core application, not an afterthought.

    The first, and most important, step we took was deciding to use REST for our API. Our philosophy was to choose the following three elements as our API’s foundation:

    1. HTTP: This covers response codes as well as operators. The operators include POST, GET, PUT and DELETE, and they can be mapped to the basic CRUD (create, read, update, delete) operations.
    2. Resources: These are the entities that the HTTP operators act on.
    3. JSON (JavaScript Object Notation): This is a data-interchange format.

    Those three elements provide everything needed for a practical REST API, including simplicity, portability, interoperability and modifiability. After the API is built, users can easily integrate against it regardless of their programming language, including C#, PHP, Node.js, Java or even cURL in a shell. They can do so without worrying about the underlying technology, including its use of multiple microservices.

    When we created the SparkPost API, we tried not to be too pedantic about following a pure REST model, opting for ease of use instead. Here are two examples that may not follow RESTful best practices:

    1. GET /api/v1/account?include=usage
    2. POST/api/v1/sending-domains/example.domain.com/verify

    The first example uses a query string parameters for GET to filter what comes back in an entity. In the second example, we use the action word “verify” in the endpoint name, which may not be RESTful. We discuss each new use case and do our best to ensure it’s consistent and easy to use.

    Related Content:

    APIs: Automation is Great. So is Usability

    Tips to Optimize the Cloud for Scaling

    Evolving and Managing Change

    We have many developers and teams working on our API’s microservices, with changes delivered on a continuous basis. We automate deployment of a change to production when an engineer (and a second) concludes it has passed our tests. It’s “released” when the product team decides we’re ready to tell customers about the change.

    We decided early on to keep our API consistent in its use of conventions and how changes are managed. We established a governance group that includes engineers representing each team, a member of the product management group, and our CTO. This group establishes and enforces our API conventions, which are thoroughly documented.

    Documenting our conventions reduces inconsistencies and makes it easier to define each new endpoint. Here are a few conventions we’ve established:

    • URL paths are lowercase with hyphens when separating words, and are case sensitive.
    • URL query parameters and JSON fields are also lowercase with underscores, and are case sensitive.
    • Unexpected query parameters and JSON fields in the request body should be ignored.

    Our governance group also sets the ground rules for how changes can be made and what types of changes are allowed. There are a number of good API changes that are beneficial to users and don’t break their integrations, including:

    • A new API resource, endpoint, or operation on an existing resource
    • A new optional parameter or JSON key
    • A new key returned in the JSON response body

    Conversely, a breaking change includes anything that could break a user’s integration, such as:

    • Changing a field’s data type
    • A new required parameter or JSON Key
    • Removal of an existing endpoint or request method
    • A materially different behavior of an existing resource method, such as changing the default for an option from “false” to “true”

    Those kinds of changes will either break users’ integrations or require the addition of a new version, which introduces more overhead.

    Don’t Break Bad When Making Changes – Nearly All the Time

    Breaking changes should be avoided, even if they’re the result of fixing bugs or inconsistencies. It’s usually better to work around such idiosyncrasies rather than risk breaking customers’ integrations. If a change is of the breaking variety, we proceed with extreme caution and seek out alternative ways to achieve our goal. Sometimes that can be accomplished by simply allowing the user to change their behavior through an account setting or an API parameter.

    However, there are times when the benefits to our users outweigh any potential negatives that would be introduced by a change. In those cases, though, we followed these best practices:

    • We received buy-in from our product, support and developer relations teams.
    • We analyzed API logs to see how many users the change might affect.
    • We gave users at least 30 to 60 days of advance warning about the change.
    • We sent an email or published a blog post containing explicit details of the change and why we were making it.
    • We provided guidance in the API documentation.

    One Version to Rule Them All

    After making thousands of changes to our API during the past three years, we’re still on the first version. We decided early on not to version our API beyond the first one because doing so adds a level of unnecessary complexity that can slow down user adoption of our latest and greatest functionality. Versioning an API can also slow down development and testing, complicate monitoring and confuse user documentation.

    In addition, not versioning our API means we can avoid the controversy that tends to swirl around the subject. There are three ways to version an API, and all of them come with potential pitfalls:

    • Put the version in the URL: Easy to do but a bad choice from a semantic perspective because the entity doesn’t change between v1 and v2.
    • Add a custom header: Also easy to do but not semantically correct.
    • Put the version in the accept header: More semantically correct but the most complicated approach.

    Use Client Libraries to Help Non-JavaScript Users

    Some of our users prefer Python, C#, Java or PHP over JavaScript. We make it quick and easy for them to integrate our API into their applications by maintaining client libraries that offer an easy-to-use set of functions for their code.

    Our client libraries have changed over time, and we do version them. We’ve learned that abstraction is hard when wrapping a living, growing API, so we focus on providing a thin layer of abstraction with some syntactic shortcuts that simplify the more complex areas of our API. Doing so lets our users quickly hit any of our API endpoints quickly and with a lot of flexibility—it also lets us “future proof” our API to some extent.

    A ‘Documentation First’ Strategy, Too

    We treat our documentation as code and use it to document our API changes before we write or change a single line of API code. Doing so helps us enforce our conventions, keeps everything consistent and maintains a good customer experience. It also cuts down on support costs.

    We maintain our documentation in GitHub, which makes it easy for technical and non-technical users to contribute changes. We’ve also found that it’s easier to review changes that way. We use API Blueprint Markdown format and Jekyll to generate the HTML docs, along with a nice search service called Algolia. Doing so lets us have full control over the customer experience, including mobile.

    For those who don’t want to “roll their own” documentation, we recommend OpenAPI (previously known as Swagger), Apiary and API Blueprint. It’s important to avoid a tool that isn’t well-suited for REST API documentation. We suggest including a bright orange “Run in Postman” button in the documentation so it’s easy to try an API, along with good examples of success and failure scenarios.

    Listen to Users

    Finally, we recommend that all developers pay attention to what their users have to say. SparkPost has a community Slack channel where thousands of users can easily access members of our product, support, engineering and executive management teams. We also have a dedicated Developer Relations team that’s squarely focused on engaging with the developer community. All of that allows us to listen to our users and incorporate their feedback into our API.

    — Chris McFadden

  • Axway Extends API Management Reach

    Axway Extends API Management Reach

    With application programming interfaces playing a larger role in the DevOps environment, Axway has added to its API toolkit for developers. The company expanded its AMPLIFY API management platform to include a visual tool for composing and integrating APIs and enhanced its API Manager tool so that it now can be invoked to scale resources up or down as needed. In addition, Axway unveiled API Central Service that makes it easier to integrate APIs across an ecosystem of organizations that make their services available via the AMPLIFY marketplace.

    Other new capabilities include an open-source MQTT connector for building internet of things (IoT) applications, a connector to the Microsoft Azure Cloud and tighter integration between Axway’s MFT file transfer software and the Syncplicity file synchronization software it acquired earlier this year.

    Axway also merged the Titantium SDK for building native mobile applications using JavaScript into the Core SDK for developers and is previewing the Query Builder Analytics tool, which enables users to do ad hoc query of mobile statistics. The Titanium code is based on technology developed by Appcelerator, which Axway acquired early last year.

    The announcements were made at the recent Axway SPARK 2017 conference. Vince Padua, vice president of platform and products for Axway, says these and other enhancements to the Axway API portfolio are intended to make it easier for organizations to craft microservices spanning multiple platforms. In some instances, those microservices will be crafted by developers, but Axway believes more advanced users will be stitching together microservices on their own using visual tools, says Padua.

    While most early use of APIs was driven by web-based applications facing external users, using APIs to interconnect services inside the enterprise now dwarfs the number of instances of published external APIs, he notes. The proliferation of those APIs has created a significant DevOps challenge for organizations and requires an API management platform to streamline the management of various back-end service. At the same time, Padua notes that DevOps teams working in collaboration with line-of-business units have taken over much of the API management, which previously was left up to individual developers. Now, IT organizations are trying to strike a balance between maintaining control and developer productivity, he says.

    The shift in API management responsibilities has also driven a wave of mergers and acquisitions over the last two years as API management has become embedded in mainstream application development platforms. But there’s also a fierce debate over the degree to which legacy API management platforms can support microservices. As microservices based on emerging technologies such as containers or more mature Java programming tools continue to evolve, API management is becoming more critically important. Each microservice generates its own API that needs to be maintained as each microservice gets continually updated. That requires an API management platform that can support all levels of API call activity that once would have been assumed to be unimaginable.

    — Mike Vizard

  • Google Launches Software Supply Chain Initiative

    Google Launches Software Supply Chain Initiative

    Maintaining the integrity of a software supply chain is an issue that has long bedeviled IT organizations. With the rise of microservices based on containers, however, this issue has become more acute. As a result, software supply chains are an issue that Google now plans to tackle.

    Google, along with JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security and CoreOS, is taking the lead on an open-source Grafeas initiative that aims to create a standard application programming interface (API) through which metadata about the software components that make up an IT environment can be more easily captured. The whole software supply chain issue has become even more challenging now that enterprise IT organizations regularly make use of open-source software within larger applications. There are now more dependencies on software modules that are being created and updated outside the IT organization, most of which are not prepared to keep track of the modules’ history.

    One of the first instances of Grafeas is going to manifest itself in the form of Kritis, a policy engine that Google has developed for the Kubernetes container orchestration engine. Because of its long history with Kubernetes, Stephen Elliott, product manager for developer platforms at Google, says Google tends to approach every issue these days through a container prism. But the expectation is that the Grafeas API will be more broadly applied to collect data about and enforce policies across a broad range of types of software components, he says.

    Elliott says that while there is no shortage of tools for managing software life cycle, each of those tools generate their own proprietary metadata. Grafeas promises to provide a consistent means to, for example, identity developers, determine when the code was checked in and built, what vulnerabilities have been detected, and what tests were passed or failed. Trying to manage those issues is at the heart of any approach to DevOps. A standard API would not only go a long way toward simplifying those issues, it also should also serve to make many of the tools DevOps teams rely on today more interoperable. That would also go a long way toward preventing IT organizations from finding themselves locked into a specific set of DevOps tools.

    Obviously, the launching of an initiative represents only the beginning of a process that should extend well into 2018. The number of IT vendors that have a vested interest in software supply chain issues exceeds that number that has signed on to the Grafeas initiative, and when this API issue is addressed by an industry standards body remains to be seen. Google is betting that as IT organizations become more familiar with microservices-based containers, there will be lot more support for addressing these issues now than anytime in the past. In the meantime, IT leaders should take some comfort in the fact that, at the very least, the IT vendor community is starting to better appreciate their software supply chain pain.

    — Mike Vizard

  • CA Technologies Acquires Runscope for API Monitoring

    CA Technologies Acquires Runscope for API Monitoring

    There’s a pressing need for a variety of monitoring tools more than ever. But given the proliferation of application programming interfaces (APIs) inside the enterprise, demand for API monitoring tools in particular is rapidly expanding. To address that requirement, CA Technologies has acquired Runscope, a provider of an API monitoring service delivered as a software-as-a-service (SaaS) application.

    Ali Siddiqui, general manager for agile operations at CA Technologies, says Runscope will complement CA Blazemeter continuous testing tools the company acquired last year and the CA API Management platform based on the technology CA Technologies gained when it acquired Layer 7 Technologies in 2013.

    While the API Economy has been a phenomenon for external-facing web and mobile applications for years now, Siddiqui notes that IT organizations have only begun to rely on APIs to ingrate internal applications in recent years. The number of private internal APIs that have been published already dwarf the number of external public APIs. Because those internal APIs have now reached a critical mass, Siddiqui says the time is now right for CA Technologies to add an API monitoring service to portfolio of DevOps tools.

    He notes that the rise of microservices inside enterprise IT organizations also will exacerbate existing API monitoring and management challenges. Each microservice generates its own API, which needs to be maintained and monitored. Before too long IT organizations will find themselves trying to unravel the interdependencies of thousands of microservices that all expose an API that can be developed in any number of programming languages.

    These days it’s not uncommon to see dedicated management teams focusing on specific APIs. Rather than treating the API as an afterthought, many IT organizations have come to realize it’s the quality and robustness of the API that ultimately determines the quality of the application experience. In fact, most service level agreements (SLAs) going forward will require access to data being generated by APIs to make sure the terms of any agreement are being met. As such, it’s starting to make sense in some organizations to organize DevOps teams around critical APIs, rather than specific elements of application logic that, in the age of the containers, will soon be more frequently updated.

    There’s no shortage of API monitoring tools these days, and Siggiqui says CA Technologies is committed to making sure the Runscope service remains open in terms of integration with other API management and testing tools. However, eventually there will be incentives provided to organizations that choose to standardize on multiple DevOps tools from CA Technologies.

    Despite the proliferation of monitoring tools, the percentage of application workloads that are instrumented remains relatively small. The reason for this is that the cost of monitoring every enterprise application has often proven prohibitive. The issue that enterprise IT organizations will have to confront as dependencies between microservices increase will be figuring out how to implement instrumentation across all those services in a way that doesn’t wind up breaking the budget.

    — Mike Vizard

  • DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

    DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

    IBM recently GA’ed perhaps its biggest zSystems mainframe release in the last decade or longer. The z14 mainframe from IBM has also been designed from the ground up to be DevOps-empowered. From APIs and other integrations to language support, the z14 is IBM’s most advanced mainframe ever. I had a chance to speak with Hayden Lindsey, VP of DevOps Enterprise Systems for IBM, about the z14.

    Hayden gives us the low-down on how the z14 has been designed to work in hybrid environments. It also works well with modern CI/CD tools such as Urban Code and others. Additionally, APIs give it the ability to integrate with many different environments, tools and apps. It is truly a mainframe for today and beyond. Hayden does a great job of describing all of this.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation. Enjoy!

    Audio

    Transcript

    [su_pullquote align=”right”] [su_custom_gallery source=”media: 117632″ width=”130″ height=”130″] Hayden Lindsey

    Hayden Lindsey, Vice President & Distinguished Engineer – DevOps for Enterprise Systems. Hayden is responsible for the development, product management, sales enablement, and services of this portfolio. He has worked at IBM for 28 years and has held a variety of positions, including software developer, product architect, product manager, co-leader of the Eclipse tools platform, and director of the WebSphere Studio/Rational modeling and construction tools. He has a bachelor’s degree in Mathematical Sciences from the University of North Carolina at Chapel Hill.[/su_pullquote]

    Alan Shimel: Hi, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Our guest on this episode of the chat is a good friend of ours, Hayden Lindsey, VP, Enterprise DevOps at IBM. Hi, Hayden, welcome to DevOps Chat.

    Hayden Lindsey: Hi, Alan. Good to be with you again.

    Shimel: Good to have you here. Hayden, it’s a big day—big day for the folks over at the IBM Enterprise team. It’s the general availability of z14 today, isn’t it?

    Lindsey: It sure is. Yes, we announced this back in the middle of July and we’ve now been making our products available. A lot of mine were available the latter part of last week, and now the box itself, GA, today. So—a big day.

    Shimel: Fantastic. And Hayden, just—you know, our audience being so focused on DevOps, they may not realize the full scale of what the z14 release is about. What it is, it’s a combination of hardware—as you mentioned, a new box. There’s a ton of software, there’s a tone of integration—it’s just chockfull of all kinds of goodies. Can you give us kind of a—at a high level, the scope of z14?

    Lindsey: Sure. And I think what you see is the result of pulling software, both middleware and tools, from the various divisions that we used to have like Rational and WebSphere and moving those into a single z or mainframe focused brand.

    And so, in contrast to most prior hardware releases where you’d be hearing about the speeds and feeds and, you know, the z13 had the fastest processor of any box on the planet—this time, the focus is more on the entire solution that involves both hardware as well as software and tools. And so I think—we worked on that, we did design thinking, we had sponsor users, we did the whole nine yards form the hardware up through the operating system, middleware, and tools, and I think that made a big difference.

    And so this time, for example, we have something called pervasive encryption. We all know how important security is, we all hear about these breaches that are happening—Experion being the most, or Equifax being the latest one. And, of all of the records that have been stolen, and I think it’s something like 9,000,000,000 since 2013—only 4 percent are encrypted. And this new mainframe lets you encrypt 100 percent of the data with no impact to performance. So, that’s just—that’s one example. Clearly, there’s hardware stuff there, but there’s also middleware that had to be involved in making this solution. So, that’s an example—it’s really cool.

    Shimel: That’s actually a big example, Hayden, because you know what? Encryption has been around—I mean, I spent 20 years in the security space and encryption has been around for most of that. The problem was the hit you took on performance when you encrypted and then had to decrypt and re-encrypt just the latency and—

    Lindsey: And the programmer had to do it. [Laughter] Or the database administrator had to set it up for the database, but then what about when it was being used in the application? And so that was—this is what is being solved, where you don’t have the time inhibitor of people doing it, and then you also don’t have the performance impact where it makes a system unusable.

    So, I think this could be really groundbreaking for the companies and the government agencies around the world that deal with sensitive data.

    Shimel: Sure—and we all do now. Hayden, you said something else, though, that I wanted to key in on, and that is sort of moving away from the speeds and feeds, if you will, metrics of—you know, to measure the value of anything. And I worked with a woman once, and she used to call that bag diving. Right? You know, when you gotta start getting into the speeds and feeds to show the value of your product, you’re diving into your bag instead of talking the true value.

    Lindsey: Right.

    Shimel: So, I’m happy to see that that’s kind of the path that IBM is taking, talking about the value, but I also think it’s a result, as you said, of so much being added into here, right, from the design thinking around the entire release, if you will, to the integration with things like cloud, with the DevOps entire tool set and methodologies that IBM and others have developed.

    This is so much more than just, “Oh, we put—this is the next iPhone with the faster processor.” This isn’t the next z with the faster processor, it’s much more than that. As I think I—maybe you said it earlier or maybe we talked about it off-mic. This is probably the most substantive release for z in at least a decade.

    Lindsey: I think it is, and of course, the market will tell us if our aspirations come to bear or not, but I certainly think the encryption element is just—well, I think it’s phenomenal, and it could be very, very, very significant for virtually any company out there.

    And then we’ve got more on machine learning and analytics so that you can do in transaction analytics rather than doing it after the fact and having to try to back out or just write off fraudulent transactions. And, of course, we’ve done a lot with our DevOps portfolio compilers. But I really do think, maybe, since we put Linux on the platform, it’s that significant.

    Shimel: Wow. Huge. So, Hayden, we are about DevOps here, so let’s focus in a little bit. I mean, one of the nice things is, I’ve seen some briefings around how you can use the new z14s with the IBM Enterprise DevOps solution and really sort of leverage—I don’t wanna use the term bimodal multi-speed nonsense. Leverage integrating your z system with cloud systems into one coherent business strategy. How’s that sound? [Laughter] So, talk about it.

    Lindsey: Yeah, so one of the three themes for the release is open and connected, and that obviously ties into a hybrid cloud strategy. It ties into, you know, a digital economy or digital transformation. It ties into API economy—whichever angle you want to take, you have to be able to make the data that resides on the mainframe, which is estimated that roughly 80 percent of the Enterprise data in the world resides on and is managed by the mainframe, and about 70 percent of the business transactions.

    And so, if you want to, though, make that available to your new iPhone X app, as we saw introduced yesterday—you know, or 10 or whatever they’re gonna call it.

    Shimel: Mm-hmm. Yeah, they’re calling it 10.

    Lindsey: They’re calling it 10 using a Roman numeral.

    Shimel: Yeah.

    Lindsey: But, you know, if you’re gonna do that, you have to make it easy to access the data and transactions, find those transactions, understand them, because very likely, they were written by somebody who’s not around any more or had moved on to other jobs. And so, you need to have tools that make API enabling and opening up and connecting to the mainframe easy and efficient, and just as easy, just as efficient as you would if you were opening up something on the Linux platform—although, of course, you have Linux on z—or a Windows box or anything else. So, that’s—it’s essential that we allow z to participate in the broader digital economy, API economy, and that’s what my team has been focusing on, along with other teams in IBM.

    Shimel: Sure. So, now, Hayden, in that same vein, you know, there’s still that mainframe attitude where, you know, we don’t open our mainframe up to all of these APIs, and maybe we don’t want to hook into our systems of engagement, you know, up in the cloud or what have you.

    For clients listening out there—and a lot of our listeners are Enterprise class, they work in Enterprise class organizations—how important is it that they really consider opening up, you know, their mainframes to this API economy, as you called it?

    Lindsey: Well, I think increasingly, certainly, the IT and line of business executives, the clients with whom I work, are realizing they have tremendous assets that they could leverage if they were to make them available. Nobody—at least no companies I know of, or government agencies, have the resources to just recreate everything from scratch. And, I think if you look back at what the analysts were saying back in the SOA era, they said, you know, it was five times faster to create a service leveraging something that exists that already does the same thing or something very similar than it is to create it from scratch—not to mention the fact that, if it already works, you’re likely to have higher quality as well. And I think the exact same analysis would prove to be true now that we’re talking more about RESTful APIs.

    So, I think more and more clients realize they need to expose that value. The key is, just, it’s sometimes daunting when you’ve got—you know, the estimate is like 250,000,000,000 lines of COBOL, not to mention PL/I and Assembler and 4GLs and so forth. It’s getting your arms around applications that were probably created in a more monolithic, less well-structured fashion. You need to do refactoring. You need to discover what is there, and then put together a plan for doing that API enablement.

    But I think people know they need to do it, it’s just, sometimes it’s viewed as a daunting task and they have to figure out how to get started, and we have something called the digital transformation model that we’re rolling out to help our clients put a plan in place.

    Shimel: Got it, and I agree. So, you’re just setting me up for my next things here, but—so, that’s the biggest question we hear at devopsy.kinsta.cloud, Hayden, which is—hey, this is all great. How do we get going? How do we roll this? How do I get executive buy-in? How do we—is there a one, two, three? Is there a blueprint I can follow.

    So, z14, let me throw it right back to you—where do we start? How do they get moving with this? How do they—and specifically, how do they start incorporating the DevOps and API stuff into this?

    Lindsey: Yeah, it’s the question that I hear from virtually every customer I talk to, and I’m getting ready to do a tour in Europe next week, and I’m sure it will come up in every single meeting. And the fact is, every customer is different, so there’s no single answer. And, within any given client, they have applications that span the gamut from nearing end of life to ones that are under active or brand new development. And so, what we’ve—but, of course, there are patterns and similarities across clients and application types, and there are best practices that we have gleaned by working with clients through the years, and that’s where I mentioned this thing called the digital transformation model.

    We’ve shifted to this way of working with our clients to focus on applications rather than one answer for the Enterprise—hey, you should start with deployment automation, or you should start with test automation. That answer should not be an Enterprise answer, it should be for this suite of applications because of what their current state is, the as-is state, and what you desire the to-be state to be. If you just need something to run efficiently and you’re gonna replace it in a few years or retire it, all you want it to do is run efficiently.

    So, use our latest compilers, but you know, the fact of the matter is, putting in a fully automated pipeline is likely a wasteful effort. Whereas, on the other end of the spectrum, for the things under very active development, that’s where you want to do DevOps in its fullest, and really, it’s just a matter of what steps do you take to get there.

    And so, this model that we’ve come up with has four levels—the first one I described about, just do your compiling, is run—just run it. Just run it efficiently. The next is maintain, the next is expose, the next is evolve. So—I mean, and I don’t know if we’ve got the best names in the world, but the fact is, you really need to think about, for the business, what degree of DevOps adoption do you need for a given application or application suite. So, that’s the more, I think, realistic answer that we’ve been using with clients this year and a tool that we’re using that’s different from what we’ve done in prior years.

    Shimel: Excellent. So, Hayden, I mean, just to illustrate this, I remember back at Interconnect last year, you know, we had the whole little DevOps TV booth set up, and I was interviewing some IBM clients. And one of them, it was a bank, and I forget if they were from Poland or the Netherlands now, or maybe even Australia. They were IBM’s z System customer and they had just updated, I wanna say, from COBOL 4 to 5—maybe it was 5 to 6, I don’t remember now.

    But they had just updated their version of COBOL, and it made a huge, huge difference for them in terms of performance and—

    Lindsey: Yeah. Yeah, exactly. You know, we’ve—one of the things that our compiler team does every single release, and this starts from the very earliest days of, we were just imagining what the new mainframe or new power platform is going to be. We were working hand in hand with the hardware folks.

    And, you know, with COBOL specifically, where something like 70 percent of the world’s business transactions are running COBOL, obviously, performance does matter, and so this is where you can get into a little bit of feeds and speeds. Mainly because, not because—some of the numbers aren’t eye popping, but it’s because you can be more responsive for your clients. But with some compute intensive apps, they run 16 times—not percent, times—faster on the latest compiler, which is 6.2, versus 4.2, which may be where that client was coming from. So, that’s skipping the version 5 things, but we still have the majority of our clients on the 4.2 version.

    So, it’s tremendously faster, but this is by doing this joint development. You know, if you put new instructions or new vector support in the hardware and the compiler doesn’t generate these new instructions, well, then, obviously, no client is gonna be able to take advantage of it unless they want to write their own assembler. So, you know, our compilers are delivering tremendous value, and I gave you a COBOL example, but you get similar results with PL/I and with our automatic binary optimizer that basically just does the, tries to do the work that the compilers do, but just working on binaries rather than having you go back to the source.

    So, it’s a big deal. You know, and the less—it’s maybe a bit more mundane. Yeah, the stuff runs faster and, as you said, diving into the bag. [Laughter] But, you know, when you’ve got numbers like 16X or 5X or what have you, that’s huge.

    Shimel: It sure is, it sure is. So, Hayden, you know, I mentioned Interconnect, too, and as we’re running low here on time, I just wanted to quickly prompt you on that and let our listeners now.

    So, this year, Interconnect is part of an even bigger kind of unified conference that IBM has put together called Think—Think 2018, I believe it’s called, and if I’m not mistaken, it’s March.

    Lindsey: Yes.

    Shimel: Go ahead.

    Lindsey: Well, you might see a trend here. [Laughter] Because, you know, Interconnect was the combination of Impact and Innovate. Innovate—I think that’s the name it was. I’ve kinda forgotten, but anyway, we had a Rational conference, we had a WebSphere conference, we had IoT stuff and all that. And now we combine those into Interconnect—at least the WebSphere and Rational stuff. And it got bigger, and now we’re doing something that is more or less IBM-wide and it’s called Think. It’s gonna be the week of March the 19th at the Mandalay Bay in Vegas, so still in Vegas like most of our other conferences have been of late.

    And so, I think there’s pros and cons to having a more broad, where we can tell the full IBM story, and that’s the focus, and you’ve got SMEs from all the different areas of the country, be it cloud, cognitive, Zpower, what have you. But I think that’s great, but because you do have those experts, and we will have the breakout sessions or keynote sessions on specific areas, be it DevOps or z or compilers or deployment automation like UrbanCode.

    So, there will be still those specialty sessions, and yet you get the big picture. And the one thing that I would like to ask your listeners is, the call for papers is open, and you know, we are shooting for having 100 percent of the talks in the various tracks either be a customer or partner only, or being customer and/or partner jointly with an IBM-er, but we’re just really trying to get away from IBM-er talking head telling a story without a partner or a customer there saying what they’ve done in real life with a given solution in a given area.

    So, we’d really love to have as many partner and client nominations as possible.

    Shimel: I love that idea. You know, I shared a panel the last two years, Hayden, on Dev—I think they were on, well, it was on DevOps and then SecOps. But, you know, I tried really hard to balance it with—yeah, we had one person from IBM, but we also had an analyst and then we’d have a partner and then a practitioner. And I think that sort of balance gives it, it makes it—

    Lindsey: It adds some legitimacy to the whole thing and different perspectives.

    Shimel: Yep. Just real quick, for anyone listening, if you go to IBM.com/events/Think, you can get all the scoop there and follow the links to submit. And as Hayden said, if you’ve got something to say and share with people, it—having been to three or four of these, or more, it’s a great platform. So, I’d encourage everyone who would like to participate to do so. And even if you don’t want to speak, but if you want to go really understand what’s happening, whether it be with Watson or z Systems or hybrid cloud or Bluemix or any of those things. You know, if any of those are important to you, I think it’s a great show to attend.

    Hayden, we’re about out of time—we’re actually over time, but that’s okay. Thanks so much for taking the time on what is a busy day with the general GA of z14. Best of luck with it. Let’s check in, I don’t know, maybe before the end of the year, and see how—you know, what kind of market reception a lot of these features and capabilities are receiving and we’ll see where the rubber is meeting the road.

    Lindsey: Sounds good, Alan, and thanks, again, for your time.

    Shimel: Thank you for your time. Hayden Lindsey, VP, Enterprise DevOps with IBM on GA Day for z Systems z14. Thanks, Hayden, have a great.

    Lindsey: Okay. Bye for now.

    Shimel: This is Alan—thank you. This is Alan Shimel for devopsy.kinsta.cloud. We’ll see you soon on another DevOps Chat.

    — Alan Shimel

  • JAMstack Radio Podcast: Benefits of an API-First CMS

    JAMstack Radio Podcast: Benefits of an API-First CMS

    Welcome to JAMstack Radio, a podcast that discusses the JAMstack, a new way to build fast and secure apps or websites. JAMstack Radio is hosted by Brian Douglas, Developer & Advocate at Netlify. In this episode, Brian is joined by Stefan Judis and Rouven Wessling to discuss Contentful, a developer friendly API-first CMS.

    They explain the benefits of decoupling your website’s content from its presentation, including better cross-platform support. With Contentful, you are completely free to write your site in the language you want, while the service takes care of the CMS backend, storing and versioning your data, and backing everything up.

    This podcast is brought to you by Heavybit, a program that helps developer product companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/329732086″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”175″ iframe=”true” /]

    Brian Douglas: So, welcome to another installment of JAMstack Radio. On the line, we’ve got Stefan Judis.

    Stefan Judis: Yeah, I am Stefan, I am a developer evangelist at Contentful, based in Berlin. And I’m really excited to be here.

    Brian: Cool, and then we also have Rouven Wessling.

    Rouven Wessling: That’s almost correct. Yeah, I’m also a developer evangelist, but I’m also an ecosystem developer, so I don’t only just get to talk about Contentful. I actually build part of the product, mainly unveiling the PHP SDK. I also have my fingers in some of the other ecosystem projects we do—stereo saturators, family integrations.

    Brian: Cool. The audience definitely knows what Contentful is, because you guys have come up in conversation at least three times in previous episodes. But for those who maybe just found this randomly, do you want to explain what Contentful is?

    Stefan: I can take it. So Contentful is a headless CMS. So what this mean is that we offer an API, where you can retrieve your content, and on the other hand, we offer a web app where editors can edit their content. That’s basically a headless CMS, and we’re API first.

    Brian: Yeah, we’re big fans. At JAMstack, we love separating concerns. And the reason why Contentful keeps coming up is because we keep talking about front end solutions, to talk to APIs, and since you guys are API first, you fit right in the middle of the jam. It’s like a match made in heaven, really, for anybody who wants to have something super fast, but not worrying about collecting and maintaining their own infrastructure.

    Rouven: There was this amazing quote from a user we had just recently.

    Contentful is a CMS where the user gets the full CMS they want, but the developer doesn’t have to deal with us at all. 

    It’s just an API, it’s like any other API you would ever use, it’s just the same. You don’t have to think like a CMS, like it worked just like a Drupal, like a Adobe experience manager of all the gruesome things out there. It’s just an API. And that’s really what we want to be, we just want to be the API for your content.

    Brian: Cool. Yeah, I really like the approach too, because I literally have recently got into WordPress, for some things we need to test for work, and I’ve never done WordPress development before.

    Rouven: How was it?

    Brian: Not very good. Just the getting up and running, and getting you environment set up to host your own WordPress setup, it’s kind of tedious. Especially if you just want to manage a small amount of content to test out a small side project. It doesn’t seem realistic to reach for WordPress right out of the gate, which is why I love the solution of Contentful. You call it a CMS, so do you have an admin interface where users can actually interface and add data too?

    Stefan: Yeah, so we’ve got the Contentful app. This is the place where content managers or editors set up their content model first, so it’s completely flexible, you’re adding there, define what your content types are, you then connect items. And then you’ve got the actual editor interface, and this is where then the data editing happens.

    Brian: Okay, cool. And then, the data itself, we’re talking JSON, I assume?

    Stefan: We’re talking JSON.

    Brian: Yeah, which is very cool. So my last job, we built a growth hacking project to get people to find our site eventually. And because it was a growth hacking project, I worked really closely with the marketing team. So what I did is I built a CMS with Google Sheets. I built a quick scraper for Google Drive, to actually take that data and add it to a Postgres database to then serve to my front-rend react app.

    So I spent about, maybe 1 1/2 weeks researching it, and I spent about another a few days to actually to implement it, and I walked away feeling very proud of myself. And the very first day I showed it to everybody in the team as like, “hey this is what I built, now the marketing team can go into the Google Drive and add data and it shows up on our website that I built for them, this works perfectly.”

    And the first question that came up with the engineering team was, Why didn’t you use Contentful? And I was like, “Content-who? I’ve never heard of these guys, I don’t understand.” And then as soon as I got back to my desk after feeling very defeated, I actually Slacked and was, “Ah yeah, if you told me about this like two weeks ago, I would have used it, but I already built this, and I don’t want to do any more work, so I’m like kind of upset.”

    Rouven: But what you built sounds amazing, because you got the core thing right. You decoupled your presentation.

    Brian: Yeah.

    Rouven: The react app is about how you displayed the content from the part where you store the content. So you can switch out either end without having to redo the entire project. Now if you worked with WordPress, and you have a WordPress theme, and you have all the content in a WordPress database, you’re stuck, it’s never going to get out of there, unless you put in a lot of manual work.

    If you want to add a mobile app, or Alexa Skill, or whatever else you want to build for your content, and you want to reuse the same content, good luck in WordPress. 

    That’s not going to fly. I mean, it’s possible, don’t get me wrong, it certainly is possible, but it’s not going to be fun, by any means. And just grasping that and actually doing that right, is where most people who build websites today actually fail. Because they are thinking in a web-centered world, and everything they design is made for the web, and for nothing else.

    Brian: That’s very true.

    Stefan: You need a mental shift though. With WordPress, you have the holy WYSIWYG editor, where people start messing around with all the content, but when you want to go cross-platform, then you’re stuck. When you have markup in your text blocks, there is no way getting out then again.

    Brian: Yeah, and especially if you have to, like you mention, handle multiple platforms, and now we have the Amazon Echo which has no actual visual interface, like it’s just reading data from strings. It makes a lot of sense to decouple your markup from your API so that way you can present that nicely.

    Stefan: And also you have much more choice of not just reusing content, but also how you have your editors think about content. Like my absolutely favorite feature of Contentful is the images API, where you can seriously resize and mitigate images on the server. And how many people implement CMSs with structured fields where you have to upload the same picture five times at different sizes for different viewport sizes.

    The editors hate it and the developers hate it but people still do it. But the much smarter solution is to resize images on the server and cache them in the CDN.

    And I’ve even seen people with Contentful implemented that way, because they are so stuck in the mindset that they have multiple image fields for different sizes, while it’s much much easier to just use the power of the platform, and just resize images on the server and be done with it.

    And to think more in abstract terms about your content, independently of the platform where you show it, is a mind shift people just have to make. And once you’re there, a whole world opens up to you of just reusing the content you have. The most amazing thing companies usually produce, is content, like this podcast, it’s content, and it’s actually really good content, cause people learn from it, people study it. Bringing the content to multiple places to be more accessible to people, is an incredibly important thing to do just to get it out there. And making that mind shift is so important.

    Brian: Reuven, at the top of the show you mentioned that you also, not only that you’re an evangelist, but you also implement some SDKs. Contentful, do they have SDKs for multiple platforms as you mentioned?

    Rouven: Yes we do. So I have the probably unpopular with this audience job of maintaining the PHP SDK. So if you’re coming from WordPress, I’m the guy who’s going to get you on Contentful. But we do have SDKs for obviously JavaScript, for all the mobile platforms, Swift, Objective C, Java for Android, Python, Ruby.

    All the common languages used on the web on mobile, we have covered. I think it’s right now eight in total, so whatever platform you’re on, we can probably get you hooked up on SDK so you don’t have to actually write raw API interactions ever.

    Brian: Cool. Yeah, that’s like the best thing about, one, separating your concerns, separating your markup, but also being able to use like, these SDKs for example, if I wanted to create a react app or ingar app, or something fancy. If I can just drop in a quick connection to that API and reuse that same data, that kind of unlocks a real world, so it makes sense how Contentful really is serving the space really nicely.

    Stefan: Yeah, you just have to drop in the JavaScript SDK and then you’re already flying.

    Brian: Yeah. Apologies if I broadside you guys with this question, but do you guys have search integrated in there as well? Like if I had a long list of content that’s being implemented, is there an easy way to pick certain items for certain situations?

    Rouven: We do have a full text search. It’s not Algolia-quality search, so if you want a really powerful full text search, use Algolia with us, it has actually quite a nice integration and there are some open-source projects to do it.

    Brian: Oh nice.

    Rouven: But if you have just basic search needs, we actually run off Postgres, we have I think like a dozen different search operators. Including like geographic searchers, range searchers, bounding box GU search, very fancy, but the most important thing is full text search across all the content users have to get you to the result. Whatever humans actually type in, not just computers do.

    But the powerful thing about Contentful is, we really just want to do one thing very well, and that is content and managing your content, and if you want another thing to do with your content, somebody else may do it better than us. So if you want really really good search for your website, or your app, or your Alexa Skill, or whatever else, use Algolia.

    Brian: Yeah.

    Rouven: Push your content from Contentful to Algolia. If you want AB test, use Optimizely.

    We want to really get away from the monolithic view of “your CMS does everything and everything lives in your CMS.

    But you use the most powerful, most advanced tool for whatever you want to do, and you just store your content with Contentful, and you integrate with all these tools. So you’re not locked into using whatever happens to integrate with Contentful, you just use whatever is the coolest thing right now.

    Brian: I’m glad you mentioned Algolia, because an episode that hasn’t been out yet, they’re actually on, I believe it’s the last episode, so the one before this will be about Algolia, which is great because all they need is JSON, which makes sense, if you guys have integration to pass your Contentful data straight to Algolia. It’s amazing how many APIs here work for each situation, and how perfect the JAMstack works.

    Stefan: You just have to connect pieces, right?

    Brian: Yeah.

    Stefan: We’re really reaching that state, and that’s quite nice.

    Rouven: It’s an amazing world we live in right now. I’ve been, the past couple of months, to a couple of API conferences. It sounds absurd on the surface, it kind of is to be honest, but like just discovering how many APIs are out there to do all the things, it’s a great world we live in.

    Brian: Yeah. Do you mind sharing what API conferences were you just at?

    Rouven: The last one I was at was actually APIdays Australia, in Sydney.

    Brian: Okay.

    Rouven: Before that it was APIdays Paris, Nordic APIs. So around the world, mostly US, Europe and Australia, there is a conference where it’s API implementers usually come together, exchanging best practices about how to best implement an API and document an API and get developers started with an API. How to make the first API call as easy as possible. This is incredibly important for us, because

    Entering your content through the web app, editors know how to do that.But integrating content through an API entry each occasion is something new for most developers. 

    So we just exchange knowledge there about actually getting started. And it’s amazing to see how many companies now open up their data. I met somebody from Lufthansa. Lufthansa, the big airline, now has an API, where you can carry flight information. I think it’s the first big airline to do it, and it’s amazing that these old like 19th century companies are starting to open up their own data for the world to use, for us developers to use.

    Stefan: Yeah, this is exactly what we wanted right? You mentioned the react use case. For example, I’m storing the information for my personal website also on Contentful. And just because I can and I have an API available, I built myself a little app that schedules all my travels. Because I do a little traveling, these are the events, and that wouldn’t be possible without an API, that’s really sweet.

    Brian: Yeah, it’s super nice. I really like the catering to, I don’t know if you want to call them non-technical users as well, but having a marketing team or an editing team that’s pushing out content while the rest of the app’s actually being built. That was one of the big use cases why I opted for building my own API-first CMS with Google Drive. It was because we were building a proof-of-concept for a project, and at the time we needed a lot of content for it.

    So we couldn’t wait for the app to be built while we were collecting content, so we started adding content to the Google Drive to eventually port it over manually. So I was like “hold on, we have the content already, let’s not double work,” so I ended up doing way too much work to get this thing to work. But if I’d used Contentful, we would have had all the content being populated as the app was being built, and then click a button and then it populates all our data. And I liked your use case for traveling too as well.

    Stefan: It works pretty well for me.

    Brian: Yeah. I love providing data. Every other episode I talk about this app, but I built an app to tell me whenever there’s a home baseball game. I don’t know if you guys have baseball in Germany.

    Rouven: Rarely. It’s not really, rumor is there is a team someplace in Germany, one, just one.

    Brian: One team? At least you’re keeping up with everybody else in the Western ecosphere. Yeah, so for the listeners who don’t know what baseball is, it’s basically where grown men stand around and watch one tiny white ball get thrown around for hours.

    Rouven: That’s so how it feels to me.

    Brian: Yeah, there’s beer involved, and hot dogs.

    Stefan: I went to a single game in my life, I was bored to death.

    Brian: Well, if you guys ever make it out here to the SF, I’ll bring you guys to a baseball game, and we’ll get drunk.

    Rouven: I think we have a deal here.

    Brian: All right.

    Stefan: I’m up for the drunk part, I’m not sure if baseball’s necessary for that.

    Brian: All right, well we’ll go next to the stadium to a bar and listen to it.

    Stefan: That’s a deal.

    Brian: So the app I built basically is just scraping ESPN data and making sure I know whenever there’s a home game for the Giants, and it just will ping me and tell me whenever not to go to the city, and avoid any sort of baseball traffic. So it sounds like I could use Contentful for that, just to collect all my data for me, and then be able to ping me with the notification, just a serverless function.

    Stefan: These kind of stories make me so excited, that we’re kind of developers and we’re able to build these kind of things. Sometimes I’m like “holy shit, this is amazing.”

    Brian: Yeah we’re at a really awesome time to be a developer, because a lot of the, not all the problems have been solved, but a lot of the hard problems have actually been solved for us, so we can just use our knowledge and collect all these APIs and collect all these use cases.

    Rouven: Just an API callable year. Google and Amazon too have been opening so many amazing APIs for natural language processing, AI context-based language meaning, image recognition, video recognition just opened by Google. I mean, it’s not open source, open source would be nicer, but just an API call away, and maybe three cents charge per API call is a breadth of knowledge, that at least I am incapable of developing by myself.

    Like I can’t build a natural language processor, that’s definitely not my level of skills. But I can just access one that’s really really good by making an API call. And that ability, as a developer, is amazing.

    Brian: Yeah. Even things like VR, and we talked a little bit about the Amazon Echo as well. People have already solved those problems, and you just drop in a JavaScript library to do VR on your phone, or language processing from your phone or other third-party device. It’s amazing and also scary. Because you know, everything’s super easy and attainable to do, so the possibilities are almost endless for the good and bad.

    Stefan: There’s always stuff to go, right, always.

    Brian: Cool. And sorry, Stefan, do you also do code at all, at Contentful?

    Stefan: I was developing many front-end stuff in JavaScript before and now anchor the developer relations team, which means I’m responsible for blogging and hanging around and chatting with people. Coding these days is side projects and try-outs.

    Brian: Okay, cool. Well I’m sure Contentful gives you access to nice stuff for your account so you can continue to build your scheduling applications.

    Stefan: I’m building all this stuff with Contentful now, I need an API, okay let’s do that.

    Brian: Yeah yeah. I feel the same way Netlify, like I’ve had three sites before I was a Netlify employee, and now I have like 50, just because I can. I don’t need to think about whether or not I need to pay for something. For one, if you’re a developer, Netlify’s pretty much free, but for two I get to try out every new feature that Netlify has, so I’m just rolling out always. If I think of something, it goes on Netlify. And hopefully I’ll do the same thing with Contentful, coming up pretty soon.

    Stefan: I tried Netlify last week the first time, and I was like, “That is nice.”

    Brian: Yeah.

    Stefan: It was really easy.

    Brian: Yeah, we try to make it easy.

    Stefan: HBB2 and CDN and yeah it was really good.

    Brian: Cool, I’m glad you liked it. So speaking of which, examples. I was trying to rack my brain, you guys have any good examples of use cases for Contentful working at companies?

    Rouven: All right, let me start. They’re not actually doing static sites, but it’s my favorite customer ever. They’re right up in London, it’s the British Museum, world-famous institution, very like old school dusty name. It’s the British Museum, they have the mummies.

    Brian: Could you do it in a British accent?

    Rouven: I can’t. You can tell my accent is horribly German and I lived in America for a year, and I still haven’t gotten over a German accent.

    Brian: Well, I don’t know if you watch any 1950s and ’60s movies, but all Germans are British in movies.

    Rouven: I haven’t heard that one. So before I left for the U.S. I was an exchange student they told me that in American TV Germans are either portrayed as Bavarians or as Nazis, so don’t be offended. So I always wanted to be the Bavarian. So the British Museum, dusty old mummy house, but they actually have an amazing digital agenda, they have a digital director.

    And Contentful is their default CMS now for all things. And they’ve done some amazing things, which is actually my favorite use case, because something nobody thought of, when they designed Contentful. Audio guides, like the things you rent for 5 pounds, and walk around the museum and they tell you about the exhibit.

    Brian: Yeah.

    Rouven: These are running off Contentful.

    Brian: Wow.

    Rouven: So all the audio files, the pictures, the text, they are stored in Contentful. The curators and the editorial team, they add to it throughout the day. So the British Museum is a very old building, with very very thick walls, which is harder for wifi, so they don’t have wifi throughout the building. So they just have wifi at the booth where they rent out these devices. And they use our sync API to sync down the entire content onto the device.

    And then you take the device, you go through the building, and you have all the content available to you, without actually connecting to Contentful. And it’s my absolutely favorite use case, because I’ve been there, I’ve used the audio guides, they’re incredibly well done, they’re informative, they have pictures. The pictures are changing while the audio’s playing, they have like the family quiz version where you have tasks to do with your kids, like do pantomimes, or makes sounds and stuff.

    So it’s incredibly good content, it’s really well presented, and using our technology to enable it. So this is my absolute favorite. They do some other things, they have some websites running, or some signage systems, but these audio guides are so amazing. If you’re in London, go to the British Museum, take five pounds, it’s going to a good cause, partly to us, get an audio guide, just experience it. They’re incredibly well done, and it’s using the same CMS you can use to call your block. Just think about that. This is a big institution with a lot of money, and they’re using the same product you can use for free to call your block. That’s my absolute favorite.

    Stefan: Yeah, speaking of which, just to make that clear. Contentful is actually a set of APIs, so it’s not just only retrieving data, we also have a read-write API, so when you need your own interface, or a simplified version for that, that’s also available, and then also preview API. So when you for example don’t want to publish stuff but want to build an environment to see edited things, this is also included.

    Brian: Okay.

    Rouven: And the Images API, my favorite API to downscale images. Also one of our APIs.

    Brian: I’ll have to check that out. And then as far as Contentful, you guys have like a trial period or a free plan to check out?

    Stefan: The free plan is up to 50,000 API calls per month.

    Brian: Oh, okay that’s totally doable.

    Stefan: I think so too, that this is enough for a side project.

    Brian: Yeah, and if you go over that then you probably want to talk about investment, and maybe getting some VC funding or something.

    Stefan: Exactly. This is the normal reaction that happens then. When you have the problem that you’re dragging 50,000 requests, you have different problems than.

    Brian: Yeah, than paying for Contentful.

    Rouven: Especially since 1,000 more API calls are just 15 cents. So if you pay us 15 cents, you get to keep using the API.

    Brian: Yeah.

    Rouven: We’re very cheap for Germans. We’re easy, just give us some beer, we’re good.

    Brian: Cool, I’ll keep that in mind, I’ll send a case of my finest Budweiser.

    Rouven: Um, Czech Budweiser you mean, not American, right?

    Brian: Well, Budweiser is not the best beer, it’s not our best export.

    Rouven: The Czech one is really good, it’s also called Budweiser, but it tastes way better.

    Brian: Cool. I really appreciate you guys talking about Contentful and kind of giving us the rundown, but for now, let’s go ahead and transition to picks, if you guys down mind. So yeah, these picks are jam picks, anything that you’re jamming on, things that are keeping you goin, that you like to do to keep your work going, or just even outside of work. So technical or non-technical are totally fine. But I’ll go first.

    My first pick is Webpack. Webpack is a build tool. A year ago I barely knew what it was. One of my lead engineers, actually Christian Schinzler, I worked with him, and he was a big Webpack fan.

    So Christian was actually on Episode Number One on the JAMstack Radio, so for anybody who remembers that far back, but yeah he was a big Webpack fan, I didn’t know anything about it. And I finally got around to actually learning it well. So I highly recommend checking out the webpackjs.org docs, because they did a really good job of making sure it was clear.

    Rouven: Version two is much better, right?

    Brian: Yeah, version two is much better, you can actually understand what’s going on, it’s very clear. So I’ve been doing offline plugins, service workers, I’ve been optimizing our build to make sure it’s not crazy heavy-weighted and stuff like that. And just from a little reading I was able to improve our bundle size and stuff like that. So highly recommend Webpack.

    My next pick is actually Service Workers, too, just roll right into that, there’s a cool offline plugin for Service Workers, which I’ve implemented in Netlify. It’s not in production yet because I’m trying to figure out some crafty ways to offline our docs to as well, currently just our homepage is offlined, so hopefully when you lose network requests on your phone or your desktop, you’ll be able to at least read our docs.

    And all that will be cached, will which be super awesome, so check that out, Webpack and Service Workers. My final pick is Luke Cage, which is a Netflix series. So I don’t know if you guys get all the Netflix series in Berlin, do you?

    Rouven: Yeah, most of them.

    Brian: Most of them? Well Luke Cage is made by Netflix, and it’s a Marvel series. He’s an African-American super hero, and he came out during the jive-talking ’70s, and that’s where he kind of was birthed in the comic books, and they’ve modernized him and put him into a Netflix series, Marvel series, and they’ve also brought along some of the ‘70s undertones too, which is really cool, a lot of the music, a lot of the stuff that came from that comic book.

    I’m very impressed that they were able to intertwine it and not make it as cheesy as the comic books were. So I just finished it, it took me a while to finish it, cause I have no time to watch TV as of late. I do a lot of coding and a lot of side projects, so I just don’t find the time. So I just finally finished the last couple episodes, so I just wanted to recommend, anybody who hasn’t seen Luke Cage, check it out, and then maybe read the comic and try not to laugh. Stefan, since I introduced you first, you have some picks you want to share?

    Stefan: Sure. One question though, have you SW Toolbox when you play around with Service Workers?

    Brian: I haven’t. What’s SW Toolbox?

    Stefan: That’s actually a Google library. And I did a Service Worker implementation six months ago, and it took a while to get my head around it, because you have to hook and to activate and fetch and all that stuff. With SW Toolbox, it’s five lines, reconfigure it, you can say cache first, network first or whatever, and I implemented it and it was like “Wow, I lost a lot of time here.”

    Brian: Yeah, I definitely did spend at least a week on just tinkering and manipulating different things and fetching and pushing.

    Stefan: Check it out, you will see that it’s not that hard then.

    Brian: Okay, cool, I will, I definitely will check it out.

    Stefan: Okay, well cool. My first pick is Unsplash, this images API, where you can get beautiful images under Creative Commons License, for free. That’s awesome, I love that. Especially when I do conference talks or something, I spend a lot of time just looking for beautiful images, so this really helps me out.

    And actually, three days ago I came across an app that is called Zoomi, or Zoom-eye, which is basically a MacOS app which queries a lot of image services that are all Creative Commons, so I now just have to type in a phrase and I can choose out of 100 beautiful images what I want to use for my presentations, so this will definitely save me some time, I recommend it.

    And extra today, when I was younger I was a little more into music, this kind of disappeared when I started coding. But accidentally I came across a band I used to listen to, which is Marot Rockel, it’s a little bit funky electronic music, and I listened to them the last time six years ago, and I discovered that they released three more albums, and I had a dancey day today, it was really good.

    Brian: A dancey day, it’s too bad this is an audio medium.

    Rouven: Stefan really cares about his stock images. Stefan is our slide quality obsessed evangelist. Whenever I had to do any presentation I had my slides to Stefan, and now I get a list, a Google Doc two pages long with all the things wrong with them back. And after I go through it they’re going to be perfect, but he’s really obsessed with the quality of his slides, and he’s great at it, so he loves his images.

    Stefan: It has to be pretty, right?

    Brian: Yeah. I was going to say I was going to look up some of your talks so I can try to mimic some of your talking in slides. Most of my slides I throw it together last minute, so you probably won’t be proud of mine.

    Rouven: Yeah, me too, Stefan is different, Stefan is amazing.

    Stefan: Well thank you.

    Brian: Reuven, you got some picks for us?

    Rouven: Yeah, of course. I’m late to the party, because I got late to Germany, but I’m really in love with the Alexa API right now. I’ve done two skills right now, I’m working on my third one, all of them using Contentful, because “ooh multi-platform.” I get to use content in a non-visual way, which is breathtaking to me still. But even beyond that, just the quality of the interaction, but also the work that goes into the interaction, and actually having to think about, “Hey how do people want to interact with something where you can’t click” is to me just fascinating.

    So I love the API, I love that I can use it AWS lamda, so I don’t have to run a server anywhere, I don’t have to think about hosting it anywhere, I just upload it to Amazon, and Amazon takes care of all the crap for me, but also the thought pattern, having to evolve from, I’ve always done either PHP band dev, or JavaScript phone-in dev, so it was always very visual, and having to think about in a different fashion is to me super engaging right now.

    And the other thing I was raving on today is, for lunch today with a co-worker I made the most awesome omelets ever in our brand new kitchen, we just moved to a new floor with my team. I just love food and today’s omelets were amazing and we had some good wine for it for lunch, and it was the best lunch I had for a long long time. It was amazing. Shout out to Linn for actually having the idea of making us omelets today.

    Brian: Nice. You can’t underestimate a good omelet. Anyway, guys thank you very much for coming on, jamming with me and talking about the JAMstack, talking about Contentful. I’m very intrigued, I’m definitely going to be using this for some future side projects, and getting real used to it.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

    — Malia Powers

  • APIs: Automation is Great. So is Usability

    APIs: Automation is Great. So is Usability

    Many developers are not so great at documentation. Ask anyone who’s been thrown into a large code base. Changes aren’t documented well, tribal knowledge thrives in the code comments, and anyone who says, “I’m confused, what does this chunk of spaghetti code mean?” is often treated with annoyance or even disdain.

    That is something that DevOps doesn’t change. And there are, as with so many things in IT right now, complicating factors. First is APIs. In almost every shop, developers are responsible for the public-facing APIs. The same developers who don’t comment well are now documenting public-facing APIs. The other complicating factor is DevOps documentation mechanisms. Automated systems generate API documentation from developer comments. Again, the same developers that often don’t document their code well enough to efficiently on-board new developers.

    Those of us who have used more than a couple of APIs know the problem intimately. Dozens, or hundreds, or thousands of us have to search for what the allowable values for a parameter or JSON field are in an API call are because far too often that is not well-documented.

    The whole system grew naturally. APIs are the realm of developers; documentation was painful to get created because it required tech writers that were advanced enough to understand the purpose and function of the API; and development of documentation delayed API deployment—all are issues that lent themselves to automated generation and the developer in the code was best-situated to document it. In the API economy, and in light of both agile and DevOps, it just made sense to use generated documentation for this part of the project.

    But we’ve got enough experience now to know that “good enough” isn’t. Far too often users are left to figure out the details, and quite often, those users don’t bother. That’s not a benefit in the API economy; it’s a risk.

    Get Help With Your APIs

    And it’s pretty easily resolvable. Get someone not knee deep in the code to try and use your API as documented. Get their recommendations on usability, and fix the issues they find. I’ve used APIs that have a dozen JSON base parameters, none of which are documented as to what’s allowed or not. I’ve used APIs where the JSON field was text, but the values were from a specialized list that was not made public and users had to hunt for allowed values. We’ve all been through it, and it is a massive waste of time.

    If you have a customer base, use Alpha/Beta users to help with this process. Early access is generally people who know the project/product, so feedback will be more focused, but as outsiders they do not share in tribal knowledge. Without tribal knowledge, they will have solid input to improve API usability.

    And in the end, an API is a consumable that you want customers to use. Telling them how to do so is important. And the current trendy way of doing so is not good enough. So make certain your process is good enough, or accept user loss as a consequence.

    For those with established products/projects, do not wag your head and assume you have it covered. Some very cool, long-lived APIs have entire sets of JSON input values that are not well-documented. They were important enough to make them parameters (or return values for that matter), yet you didn’t document them well? Please, ask new users if they agree with your assessment of your API.

    Don’t have time/man hours/whatever to address documentation shortcomings in your API? Then don’t publish an API. The only thing worse than saying, “You can’t integrate via API with our system,” is saying, “You can integrate with our system via API,” then not documenting it well enough to do so.

    So keep the automation. But follow the new mantra:

    Now that you have generated documentation, check that you have usable documentation.

    And keep kicking it. APIs are the hard part, telling people how to use them is comparatively easy, so take the time to make your development efforts worthwhile.

    — Don Macvittie

  • Node.js Becoming More DevOps-Friendly

    Node.js Becoming More DevOps-Friendly

    Over the last several years use of Node.js has exploded across the enterprise, as developers moved to embrace a variant of Javascript that made it easier to build both client and server-side applications. However, every time it is upgraded, all the dependencies between it and application modules written in C or C++ breaks.

    To solve that problem, the Node.js Foundation is making available on an experimental basis a Node.js API (N-API), developed collaboratively by Google, IBM, Intel, Microsoft, nearFrom, NodeSource and other contributors. The API will be in Node.js 8, and promises to eliminate the need to update all those dependencies. Pending additional testing, it is expected to be given Long Term Support (LTS) status later this year.

    At the same time, The Linux Foundation is adding new features to experimental tracing and async tracking features. A diagnostics API will make it easier to monitor the operation of the Node.js event loop across the complete life cycle of a service request. Finally, an inspector core module, which allows developers to leverage the debug protocol used by the Google Chrome inspector to inspect currently running JavaScript code, is also being added.

    Each of these new capabilities are nice to have on their own. But collectively, they signal the beginning of a maturation process in the Node.js community. Increased use of Javascript in general—and Node.js especially—have arguably caused many enterprise IT organizations re-evaluate their DevOps processes. Developers using Node.js have been able to increase the number of applications they could develop considerably. Since then, the number of languages being employed within the enterprise has exploded.

    Mark Hinkle, executive director of the Node.js Foundation, says moving forward there will be more focus on reducing the friction surrounding upgrades of Node.js applications as part of an effort to further expand the ecosystem. Many organizations commonly end up supporting multiple versions running across a variety of applications. Hinkle says N-API is a step in helping to reduce the maintenance costs associated with supporting those applications. In an ideal world, the foundation would be gathering additional input from DevOps experts pursuant to achieving that goal. In most IT organizations, the care and feeding of Node.js applications is still left in the hands of IT operations teams after the apps are deployed in production.

    In the meantime, Hinkle says its performance continues to improve. Naturally, there’s a corresponding relationship between better performance and the number of use cases for which it will be considered. Of course, that doesn’t mean Java and other legacy programming languages won’t be used to develop new applications. But it does means that in terms of the number of programming languages employed across the enterprise, it’s now a polyglot universe.

    — Mike Vizard