devopsy.kinsta.cloud

Tag: connectivity as code

  • 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.

  • Connectivity as Code: Making Network Security DevOps-Friendly

    Connectivity as Code: Making Network Security DevOps-Friendly

    DevOps is all about agility, with fast, short delivery cycles and automation for software development and applications. Enabled by recently introduced technologies such as virtualization, cloud and software-defined networking (SDN), spinning up new servers, provisioning storage in a public or private cloud or even launching whole environments can take just minutes or even seconds. But if that new application, service or environment needs a change in network connectivity or firewall rules to enable it to work, then the pace of delivery can often slow to a crawl.

    Unlike the typical DevOps scenario, in which developers create a CI/CD pipeline that includes running build processes and tests and delivering the new application completely automatically, provisioning new network connectivity usually involves a slow, laborious process. The application developer needs to manually open a change request and then wait for approvals and implementation of the new connectivity flow before proceeding with the DevOps flow.

    The Application Development Security Disconnect

    As part of this, the developer is usually required to provide information about firewalls, zones, subnets and other information related to the underlying network infrastructure in these change requests—information that is not always known or clear to the application developer. On the other hand, the application requirements and context are not always understood by the network security team assigned to implement the changes. This can result in back-and-forth communication between the developer and network security, making the entire process extremely long, error-prone, inefficient and frustrating to both teams.

    The challenge here is building in the necessary checks and balances to ensure that DevOps processes are not rapidly introducing security problems, while equally ensuring that security is not stepping on the brakes and slowing down the organization’s agility. So, how can this be achieved?

    The Solution: Connectivity as Code

    The answer is connectivity as code, a methodology that supports not only automation and agility in the application delivery process but also bridges the gap between application developers and network security teams on an ongoing basis, even after the application is deployed into production.

    Connectivity as code creates an abstraction layer that translates between the two worlds, giving application developers more control over their applications while helping network security understand the business impact of their day-to-day tasks, and thus ensuring business continuity.

    Establishing Connectivity Requirements

    In the first stage of this approach, the application developer describes the application connectivity requirements in a simple machine-readable text file, listing all the logical flows that represent these requirements, including those for the different application environments (e.g. test, development, production, etc.). It is presented as a list of abstract flows that typically include the source (who initiates the connection), destination (who accepts the connection), service and additional information.

    There is no need to know where the servers are located or what the underlying network topology is—such as whether there is a firewall between them or cloud security controls—or even their IP addresses or subnets. Furthermore, there also is no need to know whether connectivity is already available, because it’s also required by other applications.

    The Connectivity Phase

    Once this list is created, a new phase in the DevOps process, the connectivity phase, will automatically take care of things with no further involvement required from the application developer. The connectivity phase is where the actual connectivity provisioning and validation happens, leveraging a network security policy management (NSPM) solution to automate the network connectivity provisioning as part of the DevOps process just like any other configuration or provisioning step in the DevOps pipeline.

    The NSPM solution will read the file before automatically checking whether the connectivity requirements have changed. If no changes were made, the solution will verify that the required connectivity remains in place, and that the application will work correctly. This provides the application developer with the assurance that the necessary connectivity is in place and connectivity-related failures are not anticipated when moving into production.

    Automating Connectivity Changes

    If the connectivity requirements have changed, the NSPM solution will use the connectivity file to provision the required connectivity while retaining it for future reference, so that the application’s connectivity remains intact in the event of future network architecture changes or application or server migrations.

    If one or more of the required flows is currently blocked, a security policy change request process is triggered. Through this process a NSPM will verify that the new flows comply with the organization’s preapproved security policy, as well as security best practices and industry regulations, and will then design and implement the required changes directly on the different security devices on the network, automatically and within minutes.

    If, however, a change request is non-compliant, it will be escalated for approval and, once approved, it will be implemented automatically, thereby saving the developer the need to manually open an out-of-band change request.

    Furthermore, whenever a new version of the application is developed, this list of connectivity requirements is updated by the developer and the connectivity phase will ensure that the new flows are provisioned. With the connectivity phase completed, the DevOps process can securely proceed onto the next phase.

    The Benefits of Connectivity as Code

    Introducing the connectivity-as-code methodology into the DevOps process achieves a range of benefits. These include:

    • Seamless management of network connectivity: This makes DevOps process far faster and more agile, and enables problem-free application delivery, rather than as an external out-of-band issue that requires separate—and manual—handling.
    • Continuous compliance and auditability: Throughout the application delivery process organizations will remain fully compliant with all relevant guidelines, while all changes are fully logged for auditing purposes.
    • Business continuity: Application connectivity requirements are clearly documented and up to date, ensuring minimal disruption to the business even during network, infrastructure or architecture changes.

    Ultimately, connectivity as code bridges the gap between application developers and network security throughout the entire application life cycle, from planning and development through to deployment, production and decommissioning.  It ensures both developer and security teams get what they want: Dev teams don’t have to worry about security slowing them down, and security teams know that risk and compliance checks have been built in to the continuous delivery process, complete with a full audit trail of changes. By weaving network connectivity into the DevOps process, organizations can ensure fast delivery without any compromise in security or compliance.

    — Anner Kushnir