devopsy.kinsta.cloud

Tag: cloud-native

  • Cloud-Native: It’s One Thing

    Cloud-Native: It’s One Thing

    This Wednesday, August 10, 2022, starting at 9:00 a.m. ET, Techstrong Group is hosting an awesome virtual conference: CloudNativeDay. I am sure most of you already know a lot about the many cloud-native solutions out there; are familiar with the great work the Cloud Native Computing Foundation (CNCF) does and that you have Kubernetes clusters running in your environments. But for me, at first, the interest and enthusiasm people showed for anything and everything cloud-native defied my understanding.

    We do about one virtual conference a month here at Techstrong Group. That may sound like a lot, but when you divide it up among topics in DevOps, cybersecurity, cloud-native and digital transformation and then further segment who in an organization is targeted by those events, it doesn’t give us a lot of room to dive as deeply into some topics as we would like. We pick the topics of our virtual events carefully and we depend on feedback from you, our audience, to guide us.

    Tim Hockin, Principal Software Engineer: Kubernetes, GKE, Anthos at Google

    This is the fourth year we are producing a cloud-native virtual event, so the topic has obviously resonated with many of you. But it wasn’t until this past year that I had the “Eureka!” moment and realized why.  You see, to discover the reason why cloud-native was so popular, I looked in the usual spots: Software, applications and solutions. I felt confident that Kubernetes’ popularity was one of the reasons cloud-native was so popular. Over the last 24 months, observability burst on the scene. Maybe that was driving the continued popularity of cloud-native. Heck, the CNCF has over 40 projects; perhaps the sheer quantity is what makes cloud-native so popular. But none of that felt exactly right—yes, all of these things drive cloud-native’s popularity. But they aren’t the key driver.

    Once again this year, I had the pleasure of recording a fireside chat with Tim Hockin. If you don’t know him, Tim is a principal software engineer at Google and an original member of the team that brought Kubernetes out from Borg (if you don’t know Borg, then you need to learn some cloud-native history). This is the fourth year we have Tim keynoting this virtual conference, and chatting with him is always a highlight of the event for me.

    Tim said something in our conversation this year that finally made it click for me. Suddenly, I had found it. The “one thing”, in the immortal words of Curly from the movie City Slickers.

     

    You see, the secret to cloud-native isn’t how great and powerful Kubernetes is; it’s not what observability or service mesh or any of those great cloud-native or CNCF-developed software tools can do for you. Cloud-native is a state of mind. As much as it is about software, it is also a state of mind. Cloud-native is about building powerful, applications at scale using the entire ecosystem that was created as a result of that state of mind.

    Sound a little too zen for you? Well, I hope to change that thinking. You do not want to miss my conversation with Tim Hockin that kicks off our show this year. We’ll discuss the belief and help you understand why cloud-native is a state of mind. And, while you’re listening, Tim and I also talk about what is new in fleet and multi-cluster Kubernetes.

    The entire virtual event program is chock full of great sessions. Head over to the event site and see for yourself. Panel discussions, speakers, demos. Great exhibitor booths you can visit and ask questions. Games, prizes, a DJ, a mixologist and more. We can’t wait to see you there!

    And if you remember anything from the event, let it be this one thing: Cloud-native is a state of mind.

  • Learn Something New Every (Cloud-Native) Day

    Learn Something New Every (Cloud-Native) Day

    Being the new guy at Techstrong Group, the first couple of weeks was spent trying to find things. Like the bathroom when I’m at HQ in Boca Raton or the login to the SurveyMonkey account so I could check on the status of our various in-flight research projects. 

    I also realize I have to learn the vernacular, especially around DevOps and this cloud-native stuff. To be clear, I’ve been researching DevOps and how to integrate security into the process (yes, DevSecOps) for a while. But this cloud-native terminology is something I need to learn more about.

    You’re probably a bit confused about why I’m perplexed by the term ‘cloud-native.’ My work in cloud security for the past 10 years gave me some opinions about vernacular. When I say “cloud-native,” I’m typically referring to the native services you use in your cloud provider. Like AWS Fargate or Azure Container Registry. Those services are “native to the cloud (provider).” 

    But I’m realizing that native cloud services are only a portion of the larger cloud-native revolution. Like DevOps, cloud-native is a state of mind, not a service you buy from a cloud provider. It’s about openness. It’s about portability. It’s about agility. It’s also humbling as I realize I have a lot more to learn.

    That’s why I’m looking forward to our CloudNativeDay event on August 10, 2022. I get an opportunity to dig in and learn about some topics germane to my new coverage areas. For instance, the session on cloud-native challenges in traditional enterprises caught my eye. I’ve been involved in born-in-the-cloud companies, so we didn’t have any installed base to consider. But how would you embrace new and disruptive technology when your company has extensive legacy infrastructure? I can’t wait to hear about those more traditional enterprises’ opinions and experiences.

    Observability is also high on my list of things to learn more about. I’ve been working with customers on advanced security monitoring strategies for decades, but looking at the application layer and associated infrastructure is a different animal. I suspect there will be some technical similarities (collect data, analyze data, alert on data, etc.), but the use cases are fundamentally different. 

    I’m also excited for the last keynote of the day. However, I’m a little biased since it involves an excellent conversation Mitch Ashley and I had with Donald Lutz of Taos (an IBM company), where we dug into some of the enterprise migration challenges he’s seen in the field. 

    They say that when you’re young, you know everything. But as you get older, you realize you don’t know anything. I’m definitely in the latter camp, which is why I’m not going to squander a great opportunity to learn—and neither should you. Register and check out the event. I’ll see you there.

  • Orgs Struggle to Get App Modernization Right

    Orgs Struggle to Get App Modernization Right

    A survey published today found 93% of IT leader respondents admitted that application modernization efforts are either extremely or somewhat challenging.

    The survey, which polled 150 IT leaders at organizations with at least 1,000 employees, was conducted by Asperitas, an IT services provider. The survey found the primary issues respondents identified were identifying the right tools and technologies (30%) followed by finding staff with the right experience (20%), choosing the right external partner (18%), getting users trained on new systems (17%) and securing the support of management (11%).

    More than three-quarters of respondents (78%) said the top priority for organizations taking on application modernization should be “getting it right.”

    The definition of application modernization is, like many things, in the eye of the beholder. One-third of respondents defined modernization as the use of cloud-based infrastructure while 32% said it was moving legacy systems to the cloud. Another 22% defined it as using cloud-based tools.

    More than half of respondents (54%) said employing microservices meant that they were modernizing, while 59% said the use of any cloud-native services indicates as much.

    Scott Wheeler, practice lead at Asperitas, said that while there are a lot of definitions of application modernization, it’s clear that the lift-and-shift era of moving applications to the cloud is coming to an end. Organizations are instead preferring to build and deploy applications using a wide range of cloud-native platforms and platform-as-a-service (PaaS) environments they don’t have to manage.

    The challenge is many of these applications are being built and deployed on multiple clouds. More than a quarter (27%) said the biggest multi-cloud challenge was securing applications, followed closely by integration with on-premises systems and other cloud platforms (26%). Another 20% identified ensuring portability between platforms as the biggest challenge.

    A total of 80% also noted upskilling of internal staff and making improvements to antiquated processes were extremely important to application modernization. In fact, one of the major issues that organizations still need to address is the degree to which “bad DevOps” practices are being applied to modern application environments, said Wheeler. Much of that issue stems from the simple fact that many IT teams still don’t know how to effectively manage cloud computing platforms, he added.

    Well over a third (36%) said that a key application modernization best practice was giving yourself ample time to complete the project while an equal percentage identified avoiding shortcuts, distractions and/or partners that over-promise. Another 34% said the most important lesson was choosing the best tool for the job, while nearly a quarter (24%) identified waiting too long to modernize a system that’s clearly in need of modernization.

    A full 100% of respondents said application modernization was very or somewhat important to their business, with 45% reporting the applications they had chosen to modernize were critical. A little more than a quarter (28%) also noted modernization has enabled them to innovate faster and scale more rapidly, while 25% said it could improve end user productivity and 11% said it might make their company more attractive to employees and customers.

    Regardless of the motivation for modernizing applications, just about every organization is engaged in these efforts to varying degrees. The issue doesn’t seem to be the willingness to start these projects as much as it is making sure they are completed quickly enough to be relevant to the business.

  • A Guide to Cloud Migration Trends and Strategies

    A Guide to Cloud Migration Trends and Strategies

    For several years, we have witnessed widescale cloud adoption as a software infrastructure growth and maintenance strategy. Spending on cloud application services (SaaS) continues to grow as monolithic applications are replaced by microservices-based apps and monoliths become relics of the past. In 2021 alone, companies spent $410.9 billion on public cloud services, and Gartner expects this number to rise by 20.4% in 2022 to reach $494.7 billion. But as this movement continues to evolve, engineering leaders preparing their cloud migration strategy must be up to speed on the latest key trends.

    Is Migrating to the Cloud Cost-Effective?

    For companies migrating to the cloud now, the process is no longer a simple transition from on-premises to remotely hosted servers. Cloud service providers now offer a wide variety of options, and companies run the risk of overspending in the cloud marketplace.

    A lack of clarity of their business and product needs or submission to shiny object syndrome can drive companies to spend on non-essential services, especially during migration. It is easy to fall into this trap; companies only realize it after they have committed and try to undo the damage by reversing the process.

    Although many public cloud providers offer pay-as-you-go pricing, companies often purchase more services than they use. When companies are unclear about their objectives, such expenditure is more extravagant than the utility. This awareness of cloud spending has encouraged companies to take stock of their needs and expenses, and when they do not add up, to consider partly shifting back to on-premises.

    But Isn’t On-Premises a Thing of the Past?

    Not yet, but gone are the days of mindlessly unloading entire infrastructures into the cloud. Increasingly, companies are aware of the costs of pulling their data from the cloud.

    For many, security and control concerns motivate them to keep data on-premises. The public cloud has its benefits, but private storage has its place, too, especially for some components of your software. All in all, on-premises is here to stay, as companies continue to acknowledge and appreciate its value despite their reliance on public cloud environments.

    Why Do Companies Choose Cloud Migration in 2022?

    Cloud technologies can potentially deliver faster and better-performing experiences to end users, while innovations are giving rise to new services that cloud vendors can capitalize on. Various use cases are surfacing as companies understand the cloud better and see its potential. They are pushing the boundaries on how they can use the cloud, and cloud service providers are keeping track of the changing nature of the demand.

    For example, cloud-based gaming platforms like Amazon Luna are seeing significant growth. The cloud is also of great value to artificial intelligence and machine learning efforts, and these are often intertwined.

    The Great Resignation phenomenon also drives some companies towards the cloud. Although some knowledge is needed when moving to the cloud, cloud services offer automation and require less employee supervision in the long term.

    The COVID-19 pandemic has also been a catalyst for accelerating cloud adoption, making resiliency a priority. Companies can stay afloat in an emergency if their workloads are moved to the cloud. It comes at a cost, sure, but allows companies to outsource time-consuming responsibilities and focus resources elsewhere. While this was most significant in 2020 and 2021, this logic remains relevant.

    Cloud computing is also helping companies improve performance, efficiency and scalability. In addition to AI, the cloud will be instrumental in the development of more powerful augmented and virtual reality apps.

    Approaches Defining Cloud Migration Today

    The possibility of these approaches or facilities also motivates companies to migrate to the cloud:

    Containerization: The process of compiling and storing a service, along with its dependencies, in a container. Due to their small size, multiple containerized applications can run on a server, allowing for easier and cheaper shipping of the service. According to CNCF’s 2021 Annual Survey, containerization is now a mainstream practice, and Kubernetes, for instance, is a heavyweight in this domain, with 96% of companies employing or evaluating it.

    Security: In Q1 of 2022 alone, 90% of data breaches had their origins in cyberattacks. Mindful of this alarming trend, companies are factoring security concerns into their cloud adoption strategies. We are also witnessing a shift in businesses’ approach to security via DevSecOps: Incorporating security as a continuous practice from the beginning of the software development life cycle instead of relegating it to the back-burner until the last moment. Additionally, frameworks like secure access service edge (SASE) and customized cloud disaster recovery strategies are becoming essential elements of cloud adoption.

    Sustainability: Sustainability is becoming a key component in most business models. Companies are eager to adopt practices and models that reduce their carbon footprint. This impetus is also emerging from business partners and investors who are beginning to employ sustainability as a critical factor when deciding which companies to work with. When a cloud migration is planned carefully, chances are that you will retire certain services in your infrastructure and make decisions about what to migrate and what to retain. By optimizing your migration strategy, you are likely to only run and pay for the services you need, ensuring that your energy expenditure is under control.

    Edge computing: Edge computing, a $176 billion market in 2022, emphasizes the importance of building data centers locally; i.e., closer to where they are needed for storage and computational purposes. It solves any bandwidth and latency issues. Improved security is another added benefit of this practice. Edge computing has a bright future as it attempts to compensate for some of the pitfalls of using centralized servers in the cloud.

    Cloud-native applications: Cloud-native applications are easier to work with on the cloud, as they are designed and built on the cloud itself, not rearchitected to ensure compatibility with cloud services. When compatibility is not a concern, they can leverage various benefits offered by cloud services. As a result, scalability, flexibility and resilience are built into these applications. With cloud adoption, companies are increasingly in favor of cloud-native applications. This subsequently informs their migration strategy as they decide which services to retire, rearchitect or build anew once the actual migration is complete.

    How Does the Hybrid Cloud Fit In?

    Hybrid computing is on the rise as it leverages the public and the private cloud to deliver maximum benefit to companies with little to no compromise. The public cloud offers scalability, flexibility and speed, while the private cloud provides cost-effectiveness, security and compliance with regulations. While sensitive data can rest on the private cloud, frequently accessed data can be stored in public servers like AWS and Google Cloud. Investing in a hybrid cloud strategy from the point of migration itself can go a long way in giving companies access to the best of both worlds.

    Similar to a hybrid cloud environment, a multi-cloud strategy where companies distribute workloads across multiple clouds put some control into the company’s hands and ensures additional flexibility. By working across cloud services, companies can pick and choose which services are most compatible with their application’s components. These can include services offered by different cloud providers.

    Cloud Providers Seeing Growth, and What They are Doing Differently

    Serverless cloud environments: Cloud vendors like Amazon, Microsoft and IBM are pushing serverless cloud services. Although these continue to rely on servers (despite the name), companies don’t rent servers or pay fixed charges. Instead, the storage and bandwidth infrastructure scales with the software as and when it requires it. Companies do not need to concern themselves with technicalities and can focus on innovation and improving their existing applications. An added advantage is the provision of safe testing environments that encourage developers to tinker with cloud services and develop solutions for potential failures or outages. Serverless cloud solutions are also beneficial for smaller companies that need not invest large amounts of capital to ensure growth.

    Partnerships: To meet the soaring demand for cloud services, partnerships among cloud providers are also on the rise. By partnering with other service providers, companies can offer more services by leveraging the resources and reputations of one another while strengthening their competitive edge in the cloud market.

    Industry optimization: Cloud adoption is not limited to software companies. Businesses across industries like healthcare, finance and retail are migrating their infrastructures to the cloud. This variety in demand has encouraged providers to customize their services to meet the specific requirements of each industry. Often, these include regulatory compliance needs in these sectors.

    The cloud is only getting bigger and better. You can develop a well-curated transition strategy with the knowledge of current cloud migration trends. Additionally, identifying your requirements at an early stage will go a long way in leveraging the cloud to your advantage.

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

  • Moving From Lift-and-Shift to Cloud-Native

    Moving From Lift-and-Shift to Cloud-Native

    Analyst firm Forrester recently predicted that 2022 “will see big organizations move decisively away from lift-and-shift approaches to the cloud, embracing cloud-native technologies instead.”

    According to Gartner, more than 85% of enterprises “will embrace a cloud-first principle by 2025 and will not be able to fully execute on their digital strategies without the use of cloud-native architectures and technologies.”

    As the Gartner analysts put it, “cloud-native platforms improve on the traditional lift-and-shift approach to cloud, which fails to take advantage of the benefits of cloud and adds complexity to maintenance.”

    What’s happening here? Is lift-and-shift–long seen as a relatively quick and inexpensive way to migrate existing workloads to the cloud–really going the way of the dinosaur? Has the cloud-native future really arrived?

    I think the true answer is somewhere in the middle right now. Yes, many companies have adopted a cloud-first strategy, turning to the cloud as an assumed starting point for most or all of their application needs. But many others still have a mix of on-premises infrastructure and public cloud infrastructure with opportunistic lifting-and-shifting from one to the other rather than a holistic cloud-native model.

    Lift-and-shift has been and remains a perfectly natural and effective step in many organizations’ cloud journeys. All you do is redirect a copy of an application from an on-premises data center to the cloud–no need to redesign the app’s architecture or code.

    This method offers a fast and efficient way to leverage the cloud’s benefits: The ability to focus IT dollars on operational (rent) rather than capital (own) expense and take advantage of the extensible computing power, storage and other services in the cloud.

    In contrast with lifting and shifting, a cloud-native approach takes longer and is more labor-intensive because it takes many moving parts to redesign the entire app ecosystem. The payoff comes later with lower total cost of ownership and more flexible, responsive infrastructure.

    If many companies are still lifting-and-shifting, why are the analysts so bullish that it is on its way out? Because lift-and-shift isn’t as simple and inexpensive as it looks. It essentially defers the eventual re-engineering to cloud-native and yet still requires an investment in capacity, people, money and time.

    First, despite lift-and-shift’s promise as an easy way to migrate existing applications to the cloud, it is common for organizations, no matter how much they plan, to hit some technical roadblocks in the execution. An app that worked a certain way in the legacy environment might not work exactly the same way in the cloud, and these details must be worked out.

    Second, companies are often caught off guard by cloud “sticker shock”–the unpleasant billing surprises that occur when workloads exceed the capacity agreed on with the cloud provider.

    Third, while lift-and-shift is a way to advance on the cloud path, it’s not the ultimate destination.

    The Cloud Native Computing Foundation defines cloud-native technologies as empowering organizations “to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.”

    That’s a much bigger vision than the intermediary steps that lift-and-shift entails.

    What should companies still engaged in a lot of lifting-and-shifting be doing to prepare for their cloud-first future?

    1. Containerize like crazy. Virtualization was a game-changer because it allowed companies to abstract away hardware and run multiple virtual machines (VMs) on a single piece of hardware. This allowed a move in best practices toward a VM-per-function. Process containers, made famous by Docker and Kubernetes, are a logical extension of this concept: Stripping out redundant pieces of an operating system so that each logical unit contains only what is needed for the function it is designed to achieve. That, combined with a more deliberate approach to separating application and data, is the secret sauce of a cloud-native enterprise. Container adoption has been growing rapidly in enterprises–Gartner has predicted that containers will be the “default choice for 75% of new customer enterprise applications” by 2024. This trend bodes well for the move away from lift-and-shift to cloud-native and brings organizations closer to “write once, deploy anywhere” as each of the major cloud platforms and many on-premises tools provide mechanisms to run containers as first-class citizens.

    2. Consider the skills equation and where you want to focus your efforts. Every company embarking on a cloud-native strategy needs to carefully examine to what extent they’ll need architects and other skilled pros to carry it out. They need to think about what makes sense in terms of hiring people in-house, outsourcing to third-party experts and leveraging public cloud offerings such as serverless computing that reduce labor requirements.  It may be more sensible, for example, to focus on migrating application development to containers but rely on public cloud container platforms, low-ops Kubernetes or managed data center Kubernetes services rather than trying to build that competence in parallel.

    3. Rely heavily on automation. One of the advantages of containers encapsulating everything they need is that it makes it easier to build, test and deploy them as part of a CI/CD pipeline. Given they are also normally easier to scale horizontally, it is possible to automate how the application will scale to respond to external factors. Taking a model-driven approach to cloud-native applications can help DevOps teams and developers understand the conceptual pieces and relationships between complex software deployments while automating some of the details and life cycle management. Monitoring microservices brings its own set of challenges, so it is important to ensure that the observability tools you are using were designed to be effective with cloud-native applications. Cloud-native can bring great scalability benefits, but only with sufficient automation to limit friction in the cloud-first journey.

    4. Have a strong update strategy. Moving to containers distributes your software provenance and update problem across a much greater number of pieces; containers are not normally updated but instead are replaced with an updated version. This changes your traditional update approach. It is more important than ever that the pieces you are putting into those containers at build-time have a good software provenance and update story.

    5. Think holistically. Ruthlessly evaluate what apps can be cloud-native and which should remain in the data center and then consider the true benefits of hybrid cloud. Some organizations get caught up in thinking they need to move everything to the cloud wholesale. Maybe cloud-native isn’t right for everything.

    The industry-wide transition from lift-and-shift to cloud-native is accelerating. By keeping these five points in mind, companies can feel confident they’re moving forward, too. 

  • TechStrong Con 2022: Exploring What’s Next in Tech

    TechStrong Con 2022: Exploring What’s Next in Tech

    We have become increasingly reliant on technology and it’s hard to imagine life without all the great tech inventions we use in our daily lives. As technology keeps progressing, more is expected of IT teams, and security is a top priority.

    While we are still trying to get used to the new normal, the IT community continues to shine as a beacon, demonstrating how humans are leveraging technology to overcome the many challenges we face. On June 21, business and tech leaders who are working on transforming the world and moving it forward will come together at TechStrong Con Virtual Summit to celebrate the power of technology, share their stories, provide practical insights and lend valuable advice to help other professionals succeed in their careers. More than a virtual event, it is a community gathering that offers learning, networking and upskilling opportunities. Now in its third year, TechStrong Con continues to serve as a testament to the ways in which technology can improve human existence.

    Things You’ll Learn

    The agenda features a mix of topics including live coding, cloud-native, cybersecurity, digital transformation, observability, DevOps, open source and more. Attendees will have the opportunity to learn from some of the brightest minds in the industry about:

    • Managing the security of APIs
    • Key observability trends for 2022
    • How to accelerate digital transformation
    • Habits that will help improve your security posture
    • The state of the software supply chain post-Log4Shell
    • The distributed cloud
    • The future of data engineering
    • Building a diverse cybersecurity workforce
    • Crypto and NFTs
    • Low code and citizen development
    • The value of feature flags
    • How DevOps must be part of your future to attract the right talent
    • Managing and motivating teams in a hybrid environment

    Meet the Speakers

    The speaker lineup features globally recognized business leaders, DevOps, cybersecurity and IT experts including:

    • Sholmi Ben Haim, co-founder and CEO at JFrog
    • Chenxi Wang, founder and general partner at Rain Capital
    • John Willis, senior director of the global transformation office at Red Hat
    • Caroline Wong, CSO at Cobalt
    • Thomas Krane, principal at Insight Partners
    • Lisa Plaggemier, executive director at National Cyber Security Alliance
    • Tami Mazel Shackar, CEO at Incredibuild
    • Tom Sweet, VP in IT solutions at GM Financials

    Visit the Exhibit Hall

    In addition to the sessions, attendees can visit the virtual exhibit hall to interact with partner sponsors including Chronosphere, ConnectALL, Tidelift and TechStrong Research. The expo hall will be open throughout the event, giving attendees the opportunity to chat with the sponsors and download information at any time.

    Registered attendees will also receive a link to access the virtual environment on-demand. To see the full agenda and to register for free, please visit the TechStrong Con website.

  • DevOps/Cloud-Native Live Boston: Get Certified, Network and Grow Your Career

    DevOps/Cloud-Native Live Boston: Get Certified, Network and Grow Your Career

    DevOps and cloud-native technologies are changing the application development landscape, accelerating the pace of innovation and transforming the way organizations develop, deploy and employ modern software. The DevOps/Cloud-Native Live! event is coming to Boston on May 25 to provide attendees with all the knowledge and tools they need to succeed in the world of DevOps and cloud-native computing.

    This in-person event will bring together DevOps luminaries and cloud-native experts to discuss some of the hottest topics in the industry today, share valuable insights and offer hands-on training to all attendees to help them future-proof their careers and stay ahead of the competition.

    DevOps/Cloud-Native Live! Boston features a stellar lineup of speakers, including:

    • Tracy Bannon, software architect and DevOps advisor at Mitre Corporation
    • Andi Mann, CTO at Qumu
    • Joshua Corman, former chief strategist, CISA COVID-19 task force and founder of I am the Cavalry
    • Elizabeth Lawler, founder and CEO at AppLand
    • David Owczarek, former SRE manager at Adobe Sign
    • Daniel (Dan) Kirsch, managing director and principal analyst at Techstrong Research

    At the conference, attendees will have the opportunity to meet these leaders and speakers, exchange ideas and information with like-minded peers, attend educational sessions and get certified by completing upskilling sessions. These upskilling sessions are designed to help both new and seasoned engineers hone their skills, adapt for future growth and improve operational efficiency.

    Joshua Mazgelis, cloud architect and senior sales engineer at Progress will be conducting a hands-on training session on “Cloud Agility with Chef.” In this session, attendees will learn how they can improve cloud security and compliance without sacrificing agility and how to use Chef software to detect, correct and automate remediation of security vulnerabilities across the infrastructure.

    Check out our interview with Joshua Mazgelis below for a sneak peek of what to expect from the “Cloud Agility with Chef” upskilling session.

    [videopress oyeKYTnR]

    The agenda for DevOps/Cloud-Native Live! Boston features a mix of topics, including technical sessions, lively discussions and case studies covering digital transformation, DevOps principles, Kubernetes, cloud-native tools, DevSecOps, API security, monitoring and observability, ITIL v4 and more.

    There will also be two amazing onsite giveaways:

    • Attendees will have a chance to win a pair of tickets to a Red Sox versus Yankees game (Terms and conditions apply).
    • Attendees will get a chance to snag free tickets to a pre-release private viewing of “Top Gun: Maverick” (First come, first served).

    By visiting the expo hall, attendees will also be able to interact with sponsors and receive valuable content. Breakfast, lunch and coffee will be offered to all attendees as well.

    To see the full agenda and to register, please visit the DevOps/Cloud-Native Live! Boston website.

  • Splunk Survey Surfaces Gains in Observability

    Splunk Survey Surfaces Gains in Observability

    A global survey of 1,250 observability practitioners, managers and other experts published today by Splunk found that sophisticated observability practitioners are able to cut downtime costs by 90%. That figure is based on an estimated cost of $23.8 million annually for comparative newcomers to $2.5 million. However, only 9% of respondents are advanced enough to be considered observability leaders compared to 59% that are still beginners.

    Those leaders reported they are seeing a 69% better mean-time-to-resolution (MTTR) for unplanned downtime or performance degradation thanks to investment in observability. The survey also noted those same organizations launched 60% more products or revenue streams from application development initiatives in the last year.

    Observability has always been a core DevOps tenet, but achieving and maintaining is a challenge. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that make it simpler to launch queries and investigate anomalies.

    Spiros Xanthos, senior vice president and general manager for observability at Splunk, said observability platforms are clearly driving down the cost of downtime. There is also a clear correlation between organizations that have embraced observability and the number of microservices-based cloud-native applications that have been deployed, he noted. In effect, increased complexity is driving organizations to turn to observability platforms to manage IT environments in the age of the cloud, said Xanthos.

    The survey found 75% of respondents have multiple cloud-native applications that run in multiple environments. Just over one-third (34%) of internally developed applications are based on microservices constructed using containers, with 28% of respondents reporting they exclusively run cloud-native applications on public cloud infrastructure.

    Overall, the survey also found that two-thirds of leaders reported their visibility into application performance is excellent compared to 44% of beginners, while 64% of leaders reported that visibility into their security posture is excellent compared to 42% for beginners.

    The survey also found 59% of leaders can push code to production on demand for most internally developed applications compared to 28% of beginners. A total of 41% of leaders said they can detect problems associated with internally developed applications within minutes compared to 20% for beginners.

    It’s still early days as far as adoption of observability platforms is concerned but, theoretically, IT should become easier to manage even as the number of platforms employed continues to expand. Advances in analytics and artificial intelligence (AI) are improving the signal-to-noise ratio so that not only are more issues being surfaced sooner but that more trusted recommendations are being made, said Xanthos.

    Observability is, of course, a journey. Most organizations are not even quite sure what type of questions they should formulate to get the most value from investment in an observability platform. Organizations should start small, with a finite project to gain an understanding of how to leverage observability more broadly as they gain more maturity, said Xanthos.

    Regardless of the approach to observability, the one thing that is certain is that traditional IT monitoring is no longer sufficient in an era where IT environments get more complex by the day.

  • Container Storage for DevOps: New Options With NVMe

    Container Storage for DevOps: New Options With NVMe

    The DevOps world is ripe for a storage paradigm change, both in how it operates within the enterprise and how it implements applications. 

    NVMe, especially NVMe-over-fabrics (NVMeoF), is both a tool and a host target that can provide such a change—especially in the new world of microservices and containerization. NVMe can drastically improve application performance over classic implementations and, given the right tools, transform the process of writing those implementations to be faster, more robust and more flexible. 

    I/O-Intensive Work

    A quick recap shows why this is so. The DevOps build toolchain, especially for large codebases, has always been heavily I/O-dependent and storage access has classically been the biggest bottleneck for building an image. The ability to cluster small, inexpensive Linux x86 servers connected to SANs twenty years ago was a first step in separating storage hardware from compute, but I/O latency was pretty awful. Build/link operations could actually take longer than the compilation of object files. 

    Virtualization helped make hardware utilization better and cheaper but didn’t really improve throughput. Cloud infrastructures such as OpenStack and CloudStack made those infrastructures simpler and more elastic to manage but, again, the IOPs bottleneck remained. 

    Containerization for DevOps made it even simpler from the applications level—just deploy the app and ramp up container instances as needed—no more dedicated infrastructure needed. And it’s cheaper for incremental functions. 

    However, not much was done to clear the I/O bottlenecks for largescale storage and increasing overall performance. 

    When the new nonvolatile memory technology of NVMe came to market in 2014 for the single server world, it delivered two game-changing capabilities. 

    1. An increase of 5x disk access I/O speed. This was, arguably, the biggest single performance improvement since multicore processors with onboard cache (think Opteron) emerged. With Linux adding support for standard, open source NVMe drivers in 2021, the options increased beyond Windows and Mac users.However, SANs and their protocol stack were still an issue. SATA- and SCSI-based SANS performance was gated to the 1.2GB limitations of those technologies and big iron to head-end the SAN still dictated high-cost infrastructure.
    2. Unlike SATA or iSCSI, NVMe has the native capability for TCP/IP or fibre channel addressing. This allows NVMeoF to be an autonomous point for data storage in a normal network. A user can now keep control of their data but use network-attached compute as a utility with roughly 6Gb speed for I/O—greatly lessening the big penalty for disk I/O.  

    Applying Containers

    The dramatic uptick in container deployments and the debut of container attached storage (CAS)—software that includes microservices-based storage controllers that are orchestrated by Kubernetes—represented another industry milestone. These storage controllers can run anywhere that Kubernetes can run, which means any cloud or even bare metal servers or on top of a traditional shared storage system. Critically, the data itself is also accessed via containers as opposed to being stored in an off-platform, shared scale-out storage system. 

    Since container-attached, cloud-native storage enables the use of small, disaggregated architecture without the need for large-scale SANs or storage controllers dovetails nicely with DevOps work. 

    Container-based applications can benefit enormously from NVMe-based storage. As experts have pointed out, since DevOps applications are all about scalability, the parallelism embedded in the NVMe spec fits nicely to support them. 

    While SANs are good for large-scale contiguous operations, they’re expensive chunks of capacity and not nimble to deploy. They’re also bound to the slower I/O storage protocols, which can negate performance gains possible by adding NVMe to that array (as opposed to discretely).

    Container-based storage with NVMe gives DevOps teams the opportunity to add storage at low cost with deterministic management of that stateful storage—in theory, of course. In practice, the temptation to add like infrastructure to current infrastructure is powerful, even with all its limitations.

    To make that theory a reality, a control plane with the fast data plane is necessary—and the market is beginning to address this need.  

    As one example, OpenEBS recently introduced an upgraded engine, MayaStor (now part of DataCore Software), which enables use of NVMeoF at impressive speed: Benchmarks with Intel SPDK architecture show a 5x read/write speed improvement over SATA.

    OpenEBS debuted a few years back as a containerized storage solution for Kubernetes-based applications. With an optimized storage engine, Kubernetes has the opportunity to perform like other, more specialized hosting and development solutions. 

    Impact for DevOps

    What does this mean for DevOps teams? Firstly, using NVMe in containerized DevOps applications speeds up the time required for large builds, thereby speeding iterations of writing software. It also removes the need for complex and expensive SANs to host build environments. This double whammy of benefits means that development is quicker and cheaper and, in turn, applications can deploy faster while using more flexible tools.

    Second, NVMe greatly mitigates I/O concerns for how application code is designed and how environments are implemented. No more being beholden to the storage trunk—NVMeoF drops the performance penalty for I/O ops and distributes traffic across a normal TCP/IP network. This is now a triple whammy—faster, cheaper and more flexible containers built atop a fast, flexible virtualized infrastructure.

    Backed by innovations in container-attached storage, DevOps teams can achieve the agility and flexibility that are paramount to its mission—and act as a proving ground for the rest of the IT team to consider alternative paths to greater efficiency and performance.

    Join us for KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain (and virtual) from May 16-20—the first in-person European event in three years!