devopsy.kinsta.cloud

Tag: API gateways

  • Running Serverless in Production: 7 Best Practices for DevOps

    Running Serverless in Production: 7 Best Practices for DevOps

    Serverless in production refers to the deployment and use of serverless architecture in a live, production environment. In this context, serverless refers to a cloud computing paradigm where the cloud provider manages the infrastructure and allocates resources as needed to run and scale applications and services.

    In a serverless production environment, applications and services are broken down into individual functions triggered by events, such as API requests or changes in data. These functions are executed in response to these events and the cloud provider is responsible for managing the underlying infrastructure, including servers, storage and network resources.

    In this article, I’ll describe some of the key use cases of serverless in production and provide important best practices DevOps teams can use to run serverless in production safely and effectively.

    Use Cases of Serverless in Production

    Serverless technology has emerged as a popular choice for delivering various applications and services in production. Here is a brief overview of serverless in production for four use cases.

    Microservices

    In a microservices architecture, an application is divided into small, independent services that can be developed, deployed and scaled separately. Serverless allows each microservice to be deployed as a separate function, triggering the function only when needed and scaling it automatically based on demand. This results in a cost-effective and flexible solution for microservices, as the user only pays for the exact amount of computing resources used by each function.

    IoT Devices

    Internet of things (IoT) devices generate large amounts of data, which need to be processed and analyzed in real-time. Serverless functions can process IoT data as it is generated, allowing for real-time analytics and decision-making. With serverless, the processing and analysis can be scaled dynamically, handling spikes in data volume without the need for infrastructure management.

    Multimedia Processing

    Multimedia processing tasks, such as image and video compression, often require significant computing resources. With serverless, these tasks can be performed as functions triggered by events such as the upload of a new image or video. The serverless functions can scale automatically to handle large amounts of data, reducing the costs associated with infrastructure management and increasing efficiency.

    This function-as-a-service (FaaS) is often used for storing and processing user inputs and other data types. For example, FaaS can be used to execute specific processes according to the category of media uploaded by the user. It’s easier to build these services because the developer can write one function that is applied to multiple processing tasks. 

    APIs for Mobile and Web Applications

    APIs are an essential component of many web and mobile applications, providing access to the underlying data and services. Serverless functions can build and deploy APIs, providing a cost-effective and scalable solution. The functions can be triggered by incoming API requests and automatically scaled based on demand, allowing for fast and reliable API access for users. 

    FaaS is especially useful for RESTful applications and event-driven architectures. Containers are also useful for performing processes like API calls, but serverless functions are best suited for highly fluctuating volumes of traffic.

    Best Practices for Running Serverless in Production

    1. Monitor the Serverless Environment

    Serverless monitoring refers to the process of monitoring serverless applications and infrastructure, including serverless functions and event-driven computing services, without the need for dedicated servers or virtual machines. In a serverless architecture, computing resources are dynamically allocated and managed by the cloud provider, so there is no need for organizations to manage and maintain their own servers.

    Serverless monitoring involves monitoring various aspects of serverless applications and infrastructure, including function execution, resource utilization and performance metrics. The goal of serverless monitoring is to identify and resolve issues that may impact the performance and reliability of serverless applications and to optimize resource utilization for cost efficiency.

    By implementing serverless monitoring, organizations can ensure that their serverless applications and infrastructure are performing optimally and that they can quickly identify and resolve any issues that may arise. This helps to improve the reliability and cost-effectiveness of serverless computing and enables organizations to take full advantage of the benefits of serverless architecture.

    2. Implement Authentication

    Serverless authentication refers to the process of authenticating users and applications in a serverless architecture, where computing resources are dynamically allocated and managed by the cloud provider. In a serverless authentication model, authentication is managed through cloud-based services and APIs without the need for dedicated servers or virtual machines.

    By implementing serverless authentication, organizations can ensure that their serverless applications and services are secure and that users are only able to access the resources that they are authorized to access. This helps to improve the security of serverless applications and services and reduce the risk of security breaches.

    3. Ensure Security with API Gateways

    API gateways provide a centralized point of control and security for incoming API traffic. API gateways allow for the implementation of authentication and authorization mechanisms, such as OAuth, to control access to serverless functions. This ensures that only authorized users and clients can access the functions, reducing the risk of unauthorized access.

    API gateways can also manage incoming API traffic, such as rate limiting and request filtering, to prevent overloading the serverless functions and protect against denial-of-service (DoS) attacks. They perform real-time threat detection, identifying and blocking malicious traffic before it reaches the serverless functions. This includes protection against other common attacks such as cross-site scripting (XSS) and SQL injection.

    Finally, an API gateway can enforce encryption for incoming and outgoing API traffic, ensuring that sensitive data is protected in transit. 

    4. Assign Appropriate Roles to Functions

    With serverless, there can be many resources that must be handled, making management potentially complex. Creating minimal suitable roles for each function makes management easier, enhances security and reduces the attack surface of the serverless architecture. This approach means that the least privilege principle is applied, where a function only has the minimum permissions required to perform its intended task. It reduces the risk of unauthorized access to other parts of the infrastructure, such as sensitive data or other functions.

    The right roles ensure that functions are isolated from each other and run in their own security context. This helps to prevent the spread of any security incidents, as well as ensure that the compromise of one function does not affect the security of the rest of the system.

    5. Ensure Dependencies are Secure

    It is common for serverless functions to have dependencies from various repositories like Maven and PyPI. These dependencies may contain known vulnerabilities which can be exploited by attackers. Securing application dependencies is important to prevent security incidents and ensure the reliability and availability of the serverless architecture.  

    This involves tracking and managing the dependencies used in the serverless applications. This helps to ensure that dependencies are used in a consistent and controlled manner, reducing the risk of conflicts or compatibility issues. By regularly monitoring and updating dependencies, organizations can ensure that their serverless architecture is secure and reliable.

    6. Sanitize Inputs to Prevent Injection Attacks

    Serverless applications often use data inputs from users or events. This data enables functions such as data streaming, but the user-supplied data can also pose security risks. Sanitizing event inputs helps to prevent injection attacks—these occur when an attacker injects malicious code or data into a serverless function through the event inputs. 

    By sanitizing inputs, organizations can remove or modify potentially malicious inputs, preventing the attacker from injecting malicious code into the function. One important form of sanitization is input validation—validating that the inputs conform to a specific format or type, such as checking that a string is a valid email address. This helps to prevent attackers from injecting malicious code into the function by ensuring that the inputs are in the expected format.

    Sanitizing data is only one aspect of a defense-in-depth security strategy, which involves implementing multiple security controls to protect against attacks. It is also important to enable data escaping for SQL and noSQL databases. Likewise, the data provided by events shouldn’t be used to evaluate code at runtime or spawn system processes. 

    7. Secure Data in Transit

    Securing and verifying data in transit helps to prevent data breaches and ensure the confidentiality, integrity, and privacy of data transmitted between different parts of the serverless architecture. Here are some guidelines for securing and verifying data in transit:

    • Use HTTPS: This is a secure protocol for transmitting data over the internet. By using HTTPS, organizations can ensure that data transmitted between different parts of their serverless architecture is encrypted, preventing unauthorized access to sensitive data.
    • Implement SSL certificate verification: Verify the identity of the certificate owner and the authenticity of the certificate. This helps to prevent man-in-the-middle attacks, where an attacker intercepts and alters data transmitted between the server and the client.
    • Enable signed requests: These involve adding a digital signature to a request, which is then verified by the recipient. This helps to prevent tampering with data in transit and ensures the integrity of the data.

    Conclusion

    In conclusion, running serverless in production requires careful planning and execution to ensure the security and reliability of the architecture. By following the best practices described here, DevOps teams can reduce the risk of security incidents and ensure the reliability and availability of their serverless architecture. These include:

    • Monitoring the serverless environment
    • Implementing authentication
    • Deploying API gateways
    • Creating minimal suitable roles for each function
    • Securing application dependencies
    • Sanitizing event inputs
    • Securing and verifying data in transit 

    Additionally, regularly monitoring and updating dependencies and implementing a defense-in-depth security strategy can help organizations ensure the security and reliability of their serverless architecture over time. 

  • API Gateway Vs. Service Mesh: What’s the Difference?

    API Gateway Vs. Service Mesh: What’s the Difference?

    In the average microservices architecture, app programs trade the stability and rigidity a call stack offers for the network’s flexibility. Consequently, latency, security and traceability issues that were previously absent become a service call concern. 

    Service mesh is the resulting solution to eliminate these issues and allow developers to focus on more important business solutions. The caveat is the functionality overlap that exists between a service mesh and an API gateway. But while the two are similar, there are also key differences between both options. Here’s what you need to know.

    Defining a Service Mesh

    A service mesh is a comprehensive architectural pattern set designed to deal with enterprise concerns like instability, debugging and security. These concerns arise when a team moves from a call stack to network calls. 

    For instance, a function call via a call stack recognizes the constant availability of the requested function. On the other end of the equation, a network call doesn’t offer this functionality. 

    A service mesh is the preferred option because it assists the system’s client endpoint in managing network instability. The primary method for solving this network instability is frontrunning retries transparent from the client app’s viewpoint. 

    The service mesh also assists the server’s endpoint by rerouting incoming requests to the server node that’s best able to deal with the incoming request. The choice of server node is a function of previously determined policies for routing incoming traffic.

    The ideal service mesh is installed with two layers: The control plane and the data plane. The latter is a proxy for any connection’s server and client endpoints. 

    The data plane also enforces policies from the former while running operation metrics to a monitoring tool. Conversely, the control plane layer manages all attending service policies alongside the data plane’s operation. 

    service mesh

    Image Source

    Key Features of a Service Mesh

    The average service mesh has a number of primary features. 

    But there are a few things that bear mentioning. Say your app development team is working on a small business phone system. This particular service implementation doesn’t need every feature listed below. It depends on your team’s specific needs and traffic setup.

    Traffic Routing

    This feature enables the service mesh to route requests based on preset configuration or a predetermined policy. The system may prioritize traffic from specific client applications. Alternatively, a service mesh can re-route traffic to different service versions for:

    • A/B testing
    • Canary release
    • Service versioning

    Observability

    Service mesh implementations feature proxies that record service calls for individual clients and services. This feature takes the manual burden of the call-logging process away from the developers. 

    Plus, teams can leverage downstream analysis and monitoring tools to report on system availability and overall performance. These monitoring tools also provide a framework for basic tracing across all call chains. 

    The observability capabilities of a service mesh extend beyond the above. For example, some coding work can allow developers to improve call chain monitoring to allow for accurate tracing for enterprise business transactions.  

    Common service mesh observability features include: 

    • Latency, error rate and throughput alerts
    • On-demand service dashboards and graphs depicting the connection between individual services
    • Tracing the journey a business transaction or request makes through the service mesh

    Image Source

    Security Policies

    An application with multiple independent services has a huge attack surface. Essentially, each independent service is a vulnerable entry point that requires protection. A service mesh has proxies on both the server and client endpoints to secure any communication between both terminals. 

    A service mesh also improves security by eliminating the dependence on developers to manually program security into every service. Instead, the server proxies will handle authorization, authentication and encryption for each independent service. The resultant effect is a zero-trust security framework.  

    Identity

    A service mesh manages who can access individual services. It also maintains a real-time log of stakeholders accessing each service and when they did so. The system validates identity through JSON Web Tokens (JWTs) while allowing authorization depending on the requesting service and the stakeholder. 

    Encryption

    Compliance, security and data protection are key considerations. Well, communication between all services in a service mesh is fully encrypted. The control plane is responsible for certificate management functionality including certificate rotation and generation. 

    Furthermore, a service mesh uses mutual TLS where both server and client endpoints whitelist the certificates that can operate on the other side of any connection. A service mesh provides robust mutual TLS authentication, allowing for seamless system authentication and encryption. 

    Resilience

    This feature defines the ability of a service mesh to insulate developers in scenarios where the principal service function goes offline. In some instances, the proxy may follow an alternative service path or switch to a backup framework. 

    For illustration, streaming giant Netflix has a personalized user recommendation feature that suggests titles to its users. If this service goes offline, a service mesh system can ensure a switch to a default recommendation feature with zero personalization. Only when this backup fails will the system return an error code. 

    A service mesh assures developers that when a service fails, the proxy has done all it can to manage communication errors. In some cases, the mesh can ensure optimal performance by switching to a different service with the lowest latency.

    Examples of configurable resilience patterns for a service mesh include 

    • Circuit breaker patterns
    • Rate limiting
    • Retry policies

    Another illustration of a service mesh’s resilience is the ability to build chaos engineering capabilities. The service mesh can inject itself into the endpoints within the network, providing the observability required to monitor a chaos test. 

    Image Source

    What an API Gateway Entails

    Whether the team is working on contract management software for small business or an expense calculator app, the choice of API can determine the results of your team’s app development efforts. But more than the choice of API, proper management is another crucial talking point. The best results come with a system that identifies incoming calls, directing them to the appropriate resource. 

    API gateway is the future of DevOps and is the solution to that need. It’s the technology framework for routing API client calls to the ideal application. It also processes the call, forwarding resulting responses to the client’s network.

    At the technical level, an API gateway isn’t a must-have. Find a developer with a digital business card, hire them, and they can always program an embedded code responsible for call request routing. The only caveat to this alternative is the manpower and resources necessary to program and insert codes for individual call requests. As such, it’s always better to have an API gateway to handle this task. 

    An API gateway is a more innovative solution because extensive coding always holds the possibility of risks and errors. Furthermore, these errors can complicate app development stages like maintenance, bug fixing and application testing. 

    The API gateway ensures all API requests reach their intended destination with zero diversion. Plus, it also offers the following added functionalities:

    • API request monitoring
    • Shifting API requests between individual nodes
    • Request balancing for multiple instance situations

    The Major Differences Between API Gateway and Service Mesh

    An important digital workplace definition that differentiates both frameworks is the placement location. The API gateway is necessarily present on public-facing systems. Other key areas where an API gateway and service mesh differ include:

    Observability

    Observing the performance of the average API gateway is a more concrete task. The framework can provide actionable data insights like how long the API takes to respond to requests, problematic features, and their impact on network traffic. 

    With the service mesh, the ability to spot performance issues is a given. However, the system can’t ascertain any effects of performance lags on end-user response and experience. Therefore, while troubleshooting is easy, gauging the extent of the problem’s impact is more complicated. 

    The Communications They Handle

    Both frameworks manage different communication nodes—one handles internal discussions and the other external ones. The API gateway is the component responsible for routing external communications. For example, the API gateway handles chatbot connections, purchase orders and visits to specific pages. 

    Conversely, the service mesh is responsible for internal communications in the system. For illustration, a discussion between multiple microservices under the same app environment will fall under the service mesh’s purview. 

    In other words, the API gateway manages client-server discussions. Meanwhile, service-service communications are for the service mesh. 

    Management

    Both frameworks may have some areas of overlap, but the amount of management each one requires isn’t one of them. API gateways are simpler to manage and develop. As such, they’re easier for your app development team to manage. 

    The deployment for an API gateway happens just once, regardless of the service app. Plus, post-deployment centralization and monitoring are easy tasks. 

    In contrast, a service mesh is more complicated and tedious to manage. Your app development team must deploy the service mesh function for individual app systems. 

    Compatible Tools

    Most API gateway tools and software resources are highly expensive. Plus, they’re compatible with every popular app architecture. 

    The other end of the equation offers more accessibility. There are countless service mesh tools and resources for varied functionality. Plus, the majority of these support tools come at zero cost because they are open source.  For example, there’s Envoy and Istio, both of which are free and open source. 

    However, you shouldn’t expect to enjoy cross-platform compatibility across these service mesh tools. For example, Istio is only compatible with Google. On the other hand, AWS App Mesh—another service mesh tool—is compatible with AWS Cloud. 

    Image Source

     

    Difference  API Gateway  Service Mesh
    Existing Functionalities
    • Useful for API requests between the client and server
    • Compatible with external API requests and internal calls. 
    • Handles internal communications 
    • Best for improving the portability of service-to-service calls 
    Digital Transformation Functionality
    • Longer app delivery cycles 
    • Zero security risks
    • Useful for effective microservices management 
    • Speeds up the network’s delivery cycle 
    • Security risks due to open loopholes when the program runs alone
    Operations Reroutes API calls present outside of the given application environment  Works within the application architecture 
    Maturity Level API gateway is mature technology. It has been a core developer tool for several years now Service mesh is still a relatively new technology and requires more research and development
    Security Processing Automated security protocol Manual security systems 
    Usage Complexity Application complexity remains constant with endpoints remaining unchanged  Business scalability can be complex as each update comes with new endpoints 

    Can Service Mesh and an API Gateway Be Used Together?

    The unlikeliest of brands often form marketing partnerships. In the same way, there are instances where using both a service mesh and an API gateway is a logical and feasible idea. 

    While differences exist between an API gateway and a service mesh, it’s not an “either/or” situation.

    Cloud contact center teams looking to streamline communications at both the internal and external levels are already leveraging both technologies. And you can also leverage both systems to achieve the following:

    Improved Innovation

    Effective API use, especially during external interactions, requires internal resource optimization, which is better when teams deploy a service mesh alongside an API gateway. 

     

    Image Source

    Accelerated Digital Transformation

    Leveraging both resources improves enterprise digital transformation rates. Plus, any application with both technologies will enjoy a unified API gateway for internal service mesh management. If there are any linked applications, the unified API makes them simpler to handle.

    Increased Security Scalability

    Scalable container security is achievable when you deploy a service mesh and API gateway together. The service mech will boost the system’s interservice connectivity while the API gateway acts as a central point for all client-server requests. 

    The API gateway also provides the much-needed technical support for increased proxy security. It also fosters quick threat detection and resolution at the proxy level. 

    API Gateway and Service Mesh are Different

    Both the API gateway and service mesh are designed to simplify communication while also reducing any coding responsibility on the app development team. While both systems can ensure network calls through an enterprise contact center reach the target destination, they’re structurally different.

    Above, we’ve highlighted the key differences between both frameworks. But despite these differences, both systems are compatible and can work together for improved app development. We recommend leveraging a service mesh and an API gateway together for better security, innovation and app scalability.

  • The APIs You Really Don’t Know About

    The APIs You Really Don’t Know About

    A few years ago, we were rightly warned about the amount of exposure our APIs created. A massive attack surface that often used “security by obscurity” as its primary method of protection. We’ve come a long way since then, building secrets, tokens, RBAC and even more into our API interfaces.

    We’re still behind in getting comprehensive lists of APIs, but this bit is getting better as time moves on. Increasingly, both API management and DevSecOps markets are helping to catalog new APIs, and both the API management and application and API protection markets are helping to protect APIs that are unknown by tracking calls moving through the network. By using proxies, it is relatively easy to capture calls to APIs and report the list of APIs (and sometimes much more; about parameters and data transport, for example) to security or operations staff.

    In summary. the API management and security market has been doing great work, searching out the various APIs that are active in our systems, and cataloging new APIs as they are created. This gives us a comfortable and complete look at our current API environment and how it is protected. Most of these tools help protect what isn’t currently well protected.

    If only that really were all of the APIs in our networks. Unfortunately, that’s not the case. Because the ones not in this “complete list” can be the most insidious. As always, it is what you don’t know that poses the biggest risk.

    You see, there are APIs that are not currently maintained and are not currently actively accessed. Say you have an application that you installed from a third party—open source or purchased, either one—and then stopped accessing. Well, it is still sitting out there. The APIs are available—not necessarily documented and not necessarily secured. For security staff, this is how nightmares begin.

    Historically, we could count on these interfaces to be private. Those days are long gone in the hybrid environment. They might be private, but the definition of “private” is much looser than it has historically been and if there is a route from the internet to the API, it’s not private, and for well-known applications, is a time-bomb.

    This is another reason to clear out old versions and/or redundant installations of things like web servers and databases. Don’t make excuses—just upgrade them to the most recent version or remove them entirely. You can do this by merging what they do with a newer/better-protected installation or by just stopping them and fixing the apps that this impacts. “Turn it off and see what breaks” is admittedly a risky step, but sometimes will prove necessary to lock down the environment. If you don’t know what is using it, I’d argue your security risks are larger than an unprotected API hanging about, but that’s a topic for another blog.

    Meanwhile, keep rocking it. There is so much in your purview that we have to discuss what you don’t know about in the domain you are the specialist in. That’s not a weakness in you, that’s a statement about how much crap is tossed on your plate while making the org more competitive. And you’re dealing with it. So smile, keep kicking and lock down the scary bits.

     

  • Mastering API Gateways for the Modern Cloud-Native Enterprise

    Mastering API Gateways for the Modern Cloud-Native Enterprise

    As modern enterprises continue migrating to the cloud and the need for connected applications and devices dramatically increases, API-driven architectures are being widely adopted. In addition to the convenience of being able to efficiently connect and share resources, organizations benefit from the innovation and accelerated development speed that APIs bring in multi-cloud environments. APIs are not new, but as more enterprises adopt modern application architectures, they are increasingly occupying a large amount of a software development team’s delivery efforts. 

    When enterprises modernize and migrate to the cloud, it’s natural that challenges arise which need to be tackled before they become pain points—especially when it involves a complex microservices environment. API gateways are an essential ingredient that helps businesses overcome many of the challenges associated with APIs. API gateways are deployed at the edge of an infrastructure, responsible for routing client API requests to backend microservices. Modern API gateways also come with additional perks organizations can benefit from as teams and infrastructure grow simultaneously. 

    Let’s take an in-depth look at some of the major challenges organizations face around APIs, and how to maximize their benefits.

    Rapid Adoption Meets Growing Pains

    API-oriented architectures greatly accelerate the agility of an IT department, as they’ve become a well-known pattern for modern application architectures. However, this approach can be deceptive, as many critical issues and concerns around APIs aren’t always apparent from the onset. If they are not properly identified, they become growing pains teams have to face on a daily basis.

    The first challenge is the need to authenticate users when they make requests. API gateways allow organizations to integrate and consolidate authentication providers using their protocol(s) of choice. With billing and analytics, organizations need to understand the number of resources consumed when processing a transaction and how their customers consume their APIs. API gateways become the natural point at which to collect this data. 

    In terms of DevOps initiatives, some API gateways use service discovery to configure themselves dynamically which greatly accelerates a development and ops team’s velocity when shipping new features or fixes. To help teams deliver a highly available and resilient platform, API gateways are enablers that provide them with the puzzle pieces for advanced load balancing, rate-limiting, circuit-breakers, mirroring and more. These components make the DevOps mindset a reality. Teams can scale them as needed to realize production-grade environments, continuously updating deployments with software changes and avoiding any unintentional single points of failure (SPOFs). 

    In recent years, the evolution of API gateways has solved growing pains in the cloud, helping organizations leverage cloud-native technologies and workflows. Combining cloud-native technologies with an API-led integration platform creates an effective architecture for a digital enterprise to increase productivity. Automating production, operation and services is no longer a goal but a must-have.

    Modern API gateways features within this environment go well beyond what one would expect at first glance. API gateways can be the cornerstone of a deployment strategy transformation. With hundreds—if not thousands—of services to continuously deploy, the risk of introducing a regression to the platform soars, and being able to address this problem immediately is not enough. API gateways can help you transition to modern deployment strategies and blue/green or canary deployment becomes commonplace—helping deployments become an easily managed daily task.  

    API Gateways to the Rescue for Cloud-Native Architectures

    As part of the shift to modern application architectures, enterprises should invest resources in implementing API strategies as part of their software development initiatives. In turn, they should leverage API gateways to alleviate growing pains and simplify delivery efforts. APIs should be secured, managed, observed and even monetized. 

    API gateways can also help with critical issues related to authentication, security and SSL, billing and analytics, life cycle management, high availability and resilience, and they can even help you initiate a culture shift toward a DevOps mindset. By combining API-driven architectures and cloud-native technologies, organizations emerge with an effective architecture for the digital era. API gateways help overcome the challenges and unfold the networking intricacies of today’s cloud-centered world.

  • Linux Foundation Embraces Lightweight API Gateway

    Linux Foundation Embraces Lightweight API Gateway

    The Linux Foundation announced today that an open source application programming interface (API) gateway known as KrakenD has become the latest project it will oversee.

    Rechristened the Lura Project, the lightweight stateless API gateway was originally developed by KrakenD, which plans to continue to offer an enterprise edition of the platform.

    KrakenD CEO Albert Lombarte said the API gateway it developed provides a more streamlined approach to managing APIs that doesn’t require an organization to install a separate proxy or database. All the reverse proxy capabilities most organizations require is already embedded within the API gateway. That approach also makes it easier for IT teams to decouple back-end server applications from client applications because now an API can be more easily updated without impacting client applications, Lombarte added.

    KrakenD Linux Foundation

    Organizations that already contribute to the ongoing development of the API gateway include 99P, Hepsiburada, Openroom, Postman and Stayforlong. The API gateway also is embedded in a variety of other platforms, said Lombarte; he noted that the number of servers running the gateway now exceeds more than one million per month.

    API gateways have been available in various forms for years, but with the rise of microservices the number of APIs organizations need to deploy and manage continues to rise steadily. Each microservice added to an environment adds yet another API. At a time when microservices-based applications are at the core of many digital business transformation initiatives, IT teams must employ a more flexible approach to managing the interactions between APIs.

    Thanks in part to the role they play in enabling digital business transformations, APIs are also being targeted more frequently by cybercriminals that have come to view them as an efficient way to exfiltrate data or inject malware into an application environment.

    It’s not clear what impact the Linux Foundation’s support might have on organizations’ selection of one API gateway versus another. In fact, many organizations are still trying to navigate when to employ an API gateway versus relying on proxy software to manage a handful of APIs versus a service mesh to manage thousands. The issue comes down to not just how many APIs there are, but also the overall weight of the platform being employed, said Lombarte. A service mesh typically requires more time and effort to deploy and manage, he noted.

    As the number of APIs in an IT environment continues to increase, there may come a day when organizations will have to revisit how APIs are created and maintained. All too often, APIs are still created as an afterthought once an application is created. They tend to be brittle and, as a consequence, still break often. A more holistic approach to managing APIs based on a set of DevOps best practices is required. The challenge is getting DevOps teams to prioritize APIs when there are so many other issues that require their attention. Nevertheless, it’s become apparent APIs are, in many cases, becoming too strategic to the business for their management to be left in the hands of a single development team.

  • Dell Boomi Enhances its Enterprise iPaaS Portfolio

    Dell Boomi Announces New API Gateway and Developer Portal, Self-Service Offering, Blockchain Integration, Data Services for Pivotal Cloud Foundry, Enterprise Innovation Services and Bot SDK 

    https://boomi.com/press_release/dell-boomi-enhances-its-enterprise-ipaas/

    LAS VEGAS – BOOMI WORLD 18 – November 6, 2018 – Dell Boomi™ (Boomi), the leading transformation provider of cloud integration and workflow automation software to build The Connected Business, announced, at Boomi World 18, the company’s latest additions to its integration Platform as a Service (iPaaS) for today’s enterprise. The only vendor to offer a unified platform with built-in data quality and connectivity across the enterprise —from people, applications and databases to devices and things—Boomi defines the iPaaS industry today.

    With its latest capabilities for The Connected Enterprise —Boomi Connect Now, Boomi Data Services for Pivotal, Boomi API Gateway and Developer Portal, Bot SDK and new Professional Services offerings —Boomi provides the tools organizations need to support a breadth of use cases across all personas, ensuring both high productivity and IT control. Boomi democratizes integration, making it accessible to all users regardless of their level of technical expertise or role in the organization from citizen developers, business analysts and integration experts.

    “Sky’s mission is to connect customers to more of what they love. Dell Boomi’s ability to connect data, processes and people has an extremely positive impact on the experience Sky provides its 12 million UK customers,” said Olive Perrins, Service Strategy Manager at Sky. “Our people are critical to our success and being able to bring together our rich talent along with critical applications and data will be key to our continued success.”

    New highlights of Dell Boomi’s capabilities geared toward the enterprise include:

    • Boomi Connect Now – Allows partners and select customers to provide a centralized self-service offering for users who don’t have integration expertise. Boomi Connect Now increases productivity for the business user, customer, vendor or supplier by assisting in accomplishing quick, foolproof integrations, while IT still maintains total control.
    • Boomi API Gateway and Developer Portal – As we look to redefine the definition of integration to evolve beyond data and applications to include people, it’s increasingly important to facilitate secure and scalable interactions with external parties. By leveraging the gateway functionality, our customers will have increased confidence in the security and scalability of the services that they provide. Furthermore, with the developer portal, our customers will greatly enhance the discoverability and be able to engage at scale with their broader API consumers.
    • Data Services for Pivotal – Boomi and Pivotal now offer customers even faster deployment of the Boomi iPaaS, with deployment options available for Pivotal Kubernetes and Pivotal Application Services environments (PKS/PAS) from the Pivotal Cloud Foundry marketplace. This allows joint customers to rapidly respond to changing customer needs and provides a modernized IT infrastructure to help organizations become agile and cloud-first. Deep integration and seamless runtimes allow Boomi integration to fit seamlessly into Pivotal’s Continuous Integration and Continuous Delivery (CI/CD) framework.
    • Boomi Enterprise Innovation Services – The latest professional services offering from Boomi allows enterprise customers to collaborate with Boomi experts to achieve innovation and excellence at scale and fully capitalize on Boomi’s industry-leading integration cloud to build a connected business. Available as a subscription, Dell Boomi Enterprise Innovation Services provides a package of integration services, support and resources, with the flexibility to customize to specific customer needs.
    • Architectural Services – Allows customers to harness the full power of evolving IT architectures by partnering with Dell Boomi’s architectural experts. With this service, customers can collaborate with Boomi technical, solutions, business and enterprise architects who offer unmatched industry experience.
    • Blockchain – The evolution of business will require the ability to integrate with blockchain smart contracts. Boomi’s world-class platform offers support for the industry-leading blockchain platforms Ethereum and Hyperledger Fabric, so customers will now be ready to quickly and easily incorporate smart contracts into their business processes.
    • Bot SDK – an accelerator toolkit that packages everything a Boomi developer needs to build a bot. Customers can now achieve faster time to market with bots that are highly integrated into their existing infrastructure and optimized for lead generation and ROI in as little as 15 minutes.

    Additional Leadership Quotes

    “Just as is the case today with most businesses requiring an integration platform solution like Dell Boomi that helps them solve their integration challenges of a hybrid landscape, business will need to solve challenges that now require integration of their hybrid landscape and blockchain smart contracts,” said Michael J. Morton, CTO, Boomi.

     “We are seeing Boomi developers build their presence at every enterprise organization, extending their reach within a line of business and influencing business decisions,” said Steve Wood, Chief Product Officer, Boomi. “With the continued growth of our enterprise offerings, we are committed to improving organizational productivity and helping developers lead their organizations—whether that’s doing their own custom work in the Boomi environment, supplementing it with outside sources and expertise or providing their organization the tools it needs to enable its own citizen integrators.”

    “Perficient has strong, strategic partnerships and implementation experience with Dell Boomi and Pivotal, key technologies which support IT modernization,” said Vishal Rajpal, general manager of Perficient’s cloud platform solutions group. “The depth and breadth of our experience and expertise positions us to expertly deliver these platforms, accelerating digital transformation for our clients. Together, these technologies unleash powerful application development and cloud integration capabilities that our customers need.”

    About Dell Boomi

    Dell Boomi (Boomi), an independent business unit of Dell, is the leading provider of a unified platform to build The Connected Business, from cloud integration to workflow automation. Boomi helps organizations accelerate business agility by connecting data, applications and people to run faster and smarter. Visit http://www.boomi.com for more information.

    © 2018 Boomi Inc. Dell, Boomi, and Dell Boomi are trademarks of Dell Inc. or its subsidiaries. Other names or marks may be the trademarks of their respective owners.

  • Containers, Service Mesh and API Gateways: It Starts at the Edge

    Containers, Service Mesh and API Gateways: It Starts at the Edge

    Anyone embracing container technology such as Docker or Kubernetes has no doubt heard about the associated next big thing: service mesh, which promises to homogenize internal network communication between microservices and provide cross-cutting nonfunctional concerns such as observability and fault-tolerance. However, the underlying proxy technology that powers a service mesh also can provide a lot of value at the edge of your systems—particularly within an API gateway.

    Although it may appear that service mesh technologies have suddenly sprung up overnight, the reality is that many organizations have been using what we now identify as a service mesh for quite some time (including Verizon, eBay and Facebook). One such organization is Lyft, a U.S.-based ride-sharing service with a $1 billion annual revenue. Lyft also happens to be the creators of the open source Envoy proxy that is powering a lot of development in the service mesh space, such as the Kubernetes-native Istio control plane and Ambassador API gateway.

    The State of SOA Networking

    In a talk last year, Matt Klein, one of the creators of the Envoy Proxy, described the state of service-oriented architecture (SOA) and microservice networking in 2013 as “a really big and confusing mess.” Debugging was difficult or impossible, with each application exposing different statistics and logging and providing no ability to trace how requests were handled throughout the entire services call stack that took part in generating a response. There was also limited visibility into infrastructure components such as hosted load balancers, caches and network topologies.

    “It’s a lot of pain,” he said. “I think most companies and most organizations know that SOA [microservices] is kind of the future and that there’s a lot of agility that comes from actually doing it, but on a rubber meets the road kind of day in and day out basis, people are feeling a lot of hurt. That hurt is mostly around debugging.”

    Maintaining reliability and high-availability of distributed web-based applications was a core challenge for large-scale organizations. Solutions to the challenges frequently included either multiple or partial implementations of retry logic, timeouts, rate limiting and circuit-breaking. Many custom and open source solutions used a language-specific (and potentially even framework-specific) solution that meant engineers inadvertently locked themselves into a technology stack “essentially forever.” Klein and his team at Lyft thought there must be a better way. Ultimately, the Envoy proxy project was created to be this better way.

    Working Outside-In: Edge Proxy Benefits

    Although the open source release of the Envoy Proxy project made Klein and the Lyft engineering team look like an overnight success in September 2016, the reality was that the journey was filled with challenges over the four years from the initial hybrid-SOA Lyft architecture to their current microservice- and service mesh-enabled system. In a more recent talk at the 2017 Microservices Practitioner Virtual Summit, Klein talked about the essential need for—and associated challenges of—demonstrating business value for a technology-focused migration toward a service mesh network topology.

    Klein’s first piece of hard-won advice was, “Start with [an] edge proxy.” Microservice-based web applications need edge reverse proxying to avoid both the exposure of the internal business service interfaces (which would violate the principle of loose coupling) and the high operational overhead of exposing each service via an independent URI or RPC endpoint. Existing cloud offerings are “not so good” in this edge proxy or gateway space, or are presented to engineers as a potentially confusing range of differing products. Instead, Klein recommended starting an implementation of modern proxying technology at the edge, as this provides business value in the form of improved observability, load balancing and dynamic routing. Once an engineering team has understood how to operate proxy technology at the edge, the benefits can be rolled inward toward ultimately creating an internal service mesh.

    Evolution of the Edge: From Proxies to API Gateways

    AppDirect, an end-to-end commerce platform for managing cloud-based product and services with an estimated $50 million annual revenue, has undertaken a similar journey to Lyft, as highlighted in a recent blog post, “Evolution of the AppDirect Kubernetes Network Infrastructure.” The dynamic and ephemeral nature of cloud technology and container orchestrators such as Kubernetes, which provide many benefits in terms of scalability and resilience, mean that they are additional challenges for exposing public endpoints for business functionality provided via a composite of microservices.

    The AppDirect engineering team took a measured approach to solving these challenges, beginning with making core parts of the configuration static (such as service ports exposed) and placing a load balancer in front of each application. Their second iteration embraced more dynamism using HashiCorp’s Consul distributed key/value store and the HAProxy reverse proxy that supported “hot reloading” of configuration as it changed at runtime. Ultimately, however, the team were keen to leverage the richer functionality provided by a more fully featured API gateway.

    “The goal of our API gateway was to leave the exposed public APIs untouched and accessible even to legacy URLs and partner-customized domains, yet allow us to grow by ‘injecting’ and replacing old components one by one,” according to the blog post.

    After evaluating a series of open source and commercial offerings the AppDirect team deployed the Kubernetes-native Ambassador API gateway, which builds upon the Envoy proxy:

    “Relying entirely on the Kubernetes native API—which we know and love—Ambassador is lightweight, stateless, and uses no external datastore. Ambassador exclusively makes use of Kubernetes annotations to drive the active route configuration (i.e., it is the control plane of Envoy’s data plane),” the team noted in the blog post.

    Although AppDirect has not fully implemented a service mesh for internal communication, the company is already learning about the benefits of technology like the Envoy proxy and, critically, how to handle deployments of this in production.

    Making Sense of it All

    The adoption of service mesh technology within cloud native implementations and migrations is only just beginning, but it is already possible to identify that this technology fills a gap currently identified with modern container-based application platforms such as Kubernetes. All of the benefits of a service mesh—such as rate limiting, circuit-breaking and observability—also can be leveraged at the edge of systems. If you want to explore and learn about this technology, starting at the edge of your systems and working inward can be an effective strategy. This can also allow the technology to demonstrate value, such as improved observability and resilience, earlier than attempting to work inside out.

    — Daniel Bryant