Data is big business. As the saying goes, information is power, and this has never been truer than with traditionally hardware-focused companies shifting toward a software-based model. This digital transformation is happening across the board and is causing enterprises around the world to scramble in efforts to better grasp what’s happening on their networks and operations in order to transform their own businesses. As a result of this ongoing transition, the last few years have seen the likes of IBM and Oracle hoovering up application and cloud technology providers, driven by a need to offer end-to-end services for their customers.

Cisco’s $3.7 billion acquisition of AppDynamics earlier this year is a recent example — the latest in a long line of major tech brands betting big on application and network management technology in the age of IP. And while this has primarily been a change we are seeing in the enterprise space, it’s holding implications for the future of the telecoms sector too.

The Current State of Play

Digital Transformation (DX) continues to sweep across all industry sectors, driving the fundamental shift from physical to digital assets. Underpinning DX is the conversion towards an information-driven economy in which data is the new currency and almost all aspects of business are rooted in software. Nowhere is this more applicable than in telecom. The shift experienced by telcos has already included the move to 4G, supporting and encouraging data-hungry applications and high-bandwidth traffic. This has been great for the subscriber, who has experienced much faster speeds and better connectivity. For the operator, however, it has posed a problem.

Operators face the complex challenges of slow business growth and ongoing disruption to their core services by OTT players and new market entrants, as well as having to manage the mobile data explosion and network expansion — all while providing a consistent subscriber experience. These challenges have created a disconnect between the significant investments operators have made in 4G LTE and the decline in revenues they’ve seen thereafter.

The reality is that physical infrastructure is already being stretched in attempts to accommodate subscriber capacity demands, yet updating or expanding this architecture is a difficult and costly process. A related challenge is the sheer amount of network data that operators now need to store, process and manage as a result of meeting subscriber demands, which was supposed to be mitigated by the move to 4G. But it seems that move may actually be contributing to the problem.

New Data Demands, New Operator Challenges

4G networks, like 3G, are IP-based. However, unlike 3G,  the 4G networks also use IP for voice data. Having a common platform for all network traffic was supposed to make things run smoother, but the complexity grew and the volume of data operators had to accommodate grew substantially. As a result, the industry has been looking ahead to 5G in the hopes it will help alleviate capacity demands. But with 5G, there will be the added pressure to deliver a consistent quality of experience in an environment that forever demands higher data throughput. The volume of network data that operators will need to accommodate will also increase substantially.

Fortunately, there is light at the end of the tunnel in the form of the broader digital ecosystem and new commercial opportunities opening up to operators. With those opportunities come greater expectations from the network and new challenges for delivering on the next stage of CSPs’ digital transformation journeys. In order to meet expectations, and to create a setting in which it becomes possible for mobile operators to embrace new business models and innovate in the use of new technology for delivering new services, a new approach will be needed in terms of network design. Network design could drive DX efforts, but only if operators approach it in the right way.

The Future Will Be Virtualized

Proprietary hardware alone is simply not capable, or economic, when it comes to supporting 5G. The deployment of this technology will be enabled through network functions virtualization (NFV) and software defined networking (SDN).

The post Managing Big Data in an Era of Digital Transformation appeared first on Artificial Intelligence.

You can operate microservices without containers. However, microservices and containers are a dynamic duo, the IT equivalent of milk and cookies.

“Microservices – single-function services built by small teams, independent from other functions, and communicating only through public interfaces – simply make a great match for containers,” as Red Hat technology evangelist Gordon Haff recently noted. “Microservices plus containers represent a shift to delivering applications through modular services that can be reused and rewired to perform new tasks.”

“Containerizing services like messaging, mobile app development and support, and integration lets developers build applications, integrate with other systems, orchestrate using rules and processes, and then deploy across hybrid environments,” Haff says.

The end result: Faster and easier development, and less error-prone provisioning and configuration. “That adds up to more productive – and hopefully, less stressed – developers,” Haff notes.

As with any effort like this, you’ll want do your homework first.

“Containers are a powerful tool for increasing agility, but only if done right,” says Mike Kavis, VP and principal cloud architect at Cloud Technology Partners. “The combination of microservices, containers, and container orchestration engines can allow companies to bring features to the market rapidly while still maintaining or even improving quality, reliability, and resiliency,” Kavis says.

Read on for what you need to know before you start sprinting toward a production environment. Kavis and other experts shared advice on doing it right in our increasingly hybrid IT world.

1. You’ll need some new processes and tools

Your existing processes and toolchain probably aren’t going to cut it when you move to container-based microservices, according to Kavis. So do some real planning.

“Although it is very easy to deploy a container, much thought should be put into the operations of these systems,” he says. That thought should occur to you before a single container hits production, or you could have an operational mess on your hands, he says.

“Monitoring and managing a highly distributed and auto-scaling container-based system requires more modern tools than many are accustomed to using in the data center,” Kavis explains.

Kavis and others point out that this becomes more true – and more complex – as your container-based microservices architecture scales over time. Failing to properly plan ahead means that you’re more likely to, well, fail.

So let’s dig deeper on these best practices, tools, and other tips necessary for success.

2. Orchestration is a must…

“You won’t get very far before you’ll need a cluster scheduler/container orchestration system like Kubernetes to deploy and manage your containerized microservices,” says Nic Grange, CTO at Retriever Communications. Grange notes that you can opt for a hosted version from a public cloud provider or run the tool yourself in a private cloud or on-premises data center, depending on your preferences and constraints. But he advises choosing a cloud-agnostic tool – especially for IT leaders managing hybrid cloud or multi-cloud environments.

“The benefit of choosing a cloud-agnostic system like Kubernetes is that it can run in each of those options [public, private, on-premises] so you won’t lock yourself in,” Grange says.

3. …and so is service discovery

Here’s another one just about everyone seems to agree on: Container-based microservices almost immediately introduce the need for service discovery. Hard-coding IP addresses and hostnames? Don’t even think about it.

“Services need to register themselves and look up other services in a dynamic, automated fashion. Hardcoded IPs, server names, and even URLs will break,” says Kevin McGrath, senior CTO architect at Sungard Availability Services. “When a service launches, it should be able to register where it is, what it is, and how to use it. Other services need to be able to query this information as it will change during replacements.”

4.  Start with a greenfield project

If it’s your first foray in containers and microservices, start with a brand-new request or project, McGrath advises. This will increase the likelihood that you’ll set a high standard for a broader container-based microservices implementation, because you’ll hopefully have to make fewer of the “good enough” trade-offs required when managing legacy, monolithic applications, he says.

“It’s tempting to start chopping up a monolith as the first project out of the gate, but a small greenfield project will provide the latitude to design the microservice without legacy restrictions,” McGrath says. “This will be the target that other projects should aim to become. When starting with a monolith it is easy to make concessions early that then work into every project that follows.”

For more on how your peers are getting started using containers, see our related article, 4 container adoption patterns: What you need to know.

5. One microservice: one container

A fundamental idea underpinning microservices architecture is that a microservice should do one thing and do it exceedingly well; when deployed in containers, a similar ratio applies.

“The optimal way to scale microservices in containers is to deploy only one service per container,” Kavis says.

Containers are commonly referred to as “lightweight,” “lean,” or with similar adjectives – but you must ensure they stay that way. They’re not “free.”

“Microservices allow you to deliver your application to market in a shorter amount of time, but you’ll still need to provision resources for your microservice to run including the compute and memory to execute,” says Kong Yang, head geek at SolarWinds. Heeding the 1-to-1 rule helps realize some of the significant potential of using microservices and containers together, he says.

“Because microservices are so short-lived, running them in lightweight and portable containers make sense since VMs would be over-provisioned for your needs,” Yang says. “In other words, the symbiotic nature of microservices and containers means you can quickly provision infrastructure services, let the microservice run, and then de-provision the container to retire it cleanly.”

6. Make container security a priority

“Because containers contain system-specific libraries and dependencies, they’re more prone to be affected by newly discovered security vulnerabilities,”  as Red Hat’s Ashesh Badani, VP and general manager, OpenShift, noted in a recent article. “Trusted registries, image scanning, and management tools can help identify and patch container images automatically.

The post Microservices and containers: 6 things to know at start time appeared first on Artificial Intelligence.