In fact, you’d be hard-pressed to find an open-source software project that has seen more rapid developer adoption in the past decade. However, K8s’ ascent to ubiquity hasn’t been without its challenges. And as one might imagine, with such a sudden influx of newly minted developers, K8s adoption has come with some growing pains. 

Its widespread appropriation has transformed how developers deploy and manage applications. However, the language continues to suffer from some common misconceptions — especially that it is overly complex and unwieldy in production, and not enterprise ready. 

In fact, in a 2021 survey of IT professionals, a stunning 100% of respondents whose organizations are using or planning to use Kubernetes said that they were facing challenges with adoption, with the most commonly cited challenges being a lack of IT resources, difficulty scaling, and struggling to keep up with advancements in underlying technologies. However, what these findings fail to recognize is that much of these perceived shortcomings and challenges are not necessarily inherent to Kubernetes itself. Instead, as we’ll outline below, many of these challenges stem from some fundamental misunderstandings of how to approach and conceptualize the K8s system. 

The #1 mistake

The single most widespread and detrimental mistake developers make when working in Kubernetes is actually one of mindset — the all-too-common mistake of bringing monolithic logic into the cloud-native space. Kubernetes offers a plethora of abstractions and resources designed for the cloud-native ecosystem. Failing to leverage these resources appropriately can lead to scalability issues, maintenance challenges, and inefficient application and database deployments. This misconception can also foster the belief that Kubernetes and the cloud-native paradigm are unsuitable for enterprise use, while in reality, it highlights the necessity of adapting application architectures to harness the full power of containers and orchestration.

To remedy this common mistake, teams should embed strong architecture expertise into their development processes. Having engineers with cloud-native experience can guide teams to success and help them avoid common pitfalls. This approach emphasizes the importance of understanding and adapting to the unique characteristics of Kubernetes and cloud-native development.

Cloud-native thinking

The best way to avoid future mistakes is to cultivate cloud-native thinking and experience within development teams. Encourage continuous learning and training on Kubernetes best practices, and encourage teams to participate in the K8s community. Promote a culture of collaboration and knowledge-sharing, allowing team members to benefit from each other’s experiences and insights. Regularly reassess and update development practices to align with the evolving Kubernetes landscape.

Establishing high standards and quality control measures is also essential for successful Kubernetes development. Platform teams should enforce rigorous standards for anything deployed in Kubernetes, leading to higher availability, improved security, and enhanced performance. Operators can be valuable tools in this regard, automating the deployment of applications with best practices right out of the box.

Microservices is an architectural style that is increasingly adopted by software development teams. The shift from monolithic to a collection of small autonomous services is a good first step towards cloud native. Microservices architecture offers various benefits such as flexibility in using different technologies, ease of understanding, adaptability, and scalability. 

And with growing interest in running databases on Kubernetes, this becomes even more challenging. It’s essential that businesses demand enterprise-grade functionality in operators, ensuring that databases on Kubernetes are deployed using modern and efficient approaches.

By understanding the most common pitfalls and looking to more experienced developers, newcomers can adopt best practices, embed strong architecture expertise, set high standards, and leverage modern approaches to fully harness the power of Kubernetes in the cloud-native ecosystem — ensuring a smoother journey into the world of Kubernetes development, and paving the way for more scalable, efficient, and secure applications.

The post Navigating Kubernetes: The common mistake newcomers make appeared first on SD Times.

“Containers are more popular than ever. Here at Oracle, we use containers for many of our cloud services. While preparing for containers in production, we developed tools to help with building and operating containers,” Vish Abrams, architect for cloud development at Oracle, wrote in a post.

Smith is a secure microcontainer builder. This solution is designed to help operators deal with container images. “Unfortunately, while the standard build process for containers is ideal for developers, but the resulting container images make operators’ jobs more difficult,” Abrams wrote.

The problems it solves include large images, privilege escalation, vulnerability management, lack of user namespaces, layers, and overlays. According to Abrams, microcontainers help by providing better security and stability. Smith allows users to build microcontainers that only containers the process to be run and direct dependencies, has files with no user ownership, and is able to run read-only.

Crashcart is a microcontainer debugging tool that helps users containerize their applications and connect to the database. “Containers can be a challenge to debug, especially when you are a little fuzzy on exactly what a container is and how it works. Some people treat containers like miniature vms, and go so far as to run an ssh daemon inside their container so that they can login when things go crazy. Others stick a bunch of useful tools inside their container and use `docker exec` to get a shell inside their container. But for those of us with slightly-more-sane operational practices, what do we do when things go wrong” Abrams wrote.

Crashcart also aims to make debugging easier by providing tricky hacks and mounting tools to containers on demand. It enables users to load binaries into a container to figure out problems. Currently, Crashcart doesn’t work with user namespaces prior to kernel 4.8, according to the project’s GitHub page. Oracle plans to add more functionality and capabilities to the tool such as the ability to set uid and gid in the containers.

RailCar is an alternative container runtime impentation built with Rust. “These days, almost all container utilities are in c or go. c is great for interacting with the linux kernel, but has security drawbacks. Go is great for speed of development and memory safety, but it has some limitations that create problems interacting with namespaces. Rust sits at a perfect intersection of these two languages: it has memory safety and higher-level primitives, but doesn’t sacrifice low level control over threading and therefore can handle namespaces properly. It is a great choice for container utilities and we hope to see the rust community and the container community collaborate more in the future,” Abrams wrote.

According to Abrams, Railcar is similar to runc, but with Rust it is able to provide memory safety without any overhead.

All three projects are available on Oracle’s GitHub page.

The post Oracle open sources new tools focused on containers appeared first on SD Times.

The program is designed for IT operations teams and consists of professional services, Docker Enterprise Edition Standard for app management, and hybrid cloud infrastructure. The program takes existing legacy app, and containerizes them to give them the portability, security and efficiency of being inside a Docker container without having to re-architect the application. “As a result, they are able to get a lot of value over their current application investments without having to go through a full development cycle with a full application refresh,” said Scott Johnston, COO at Docker. “Businesses can take a single legacy application, containerize it, put it on modern infrastructure, put it under Docker management, and see the value in five days or less.”

In a recent pilot program, the Docker program helped its customer Northern Trust, a financial services company, modernize its existing applications. According to Johnston, through the program Northern Trust reduced its provisioning time of the app from 29 days to 7 days, was able to get the same performance using half the infrastructure, improved the software security, and added built-in features that enabled self checking and healing.

Johnston explains that less than 10% of Docker’s customers actually take the jump to refactor or re-architect their applications into modern apps because it is very extensive and risky. “Enterprise IT tries to manage change very carefully, and big changes equate in their minds to big risks,” he said. By providing them the Docker program, they get an entry point or stepping stone towards modern applications, Johnston explained.

“It really gives them a lot of control over managing technology adoption risks and timing. If you splash into the deep end of the pool and do a full refactor, you are taking a lot of risks,” he said.

In addition, the company announced Oracle is joining the Docker store where it will publish its certified containers including: Oracle Database, Oracle Java Development Kit, Oracle WebLogic Server, Oracle HTTP Server, Oracle Coherence, and Oracle Instant Client.

The post DockerCon: Docker plans to modernize traditional legacy apps appeared first on SD Times.

In fact, recent joint research from Red Hat and Bain & Company uncovered that enterprises using containers are beginning to realize material architectural benefits. According to the report, initial container adopters could realize:

• A 15% to 30% reduction in development times, and additional infrastructure flexibility gains driven by the portability benefits of containers.
• Cost savings of 5% to 15% from hardware productivity.

Red Hat and Bain expect container adoption to grow across all app life-cycle phases, especially the production phase. But as IT and business pros continue to evaluate container technology, many are feeling overwhelmed by the amount of often-confusing information out there.

In the end, it’s actually simple: Containers are just fancy files and fancy processes. So, how exactly do they work?

First let’s go back to something that all of us understand from using our computers and smartphones: the program. But, what is a program anyway? Well, that depends on what it’s doing. When a program is first installed on your computer or smartphone, it’s really just a file. When you start the program, it’s loaded into the memory of the device and the operating system allocates CPU to execute it. The operating system also serves as a traffic cop, deciding whether a program can access a file or connect to the network. The operating system, and more specifically the operating system kernel, are key to running programs.

The same is true with containers: They can be started, stopped and moved around just like normal Linux programs, but much more quickly and easily.

Like normal programs, containers really have two different states: running and not running. When a container isn’t running, it’s really just a set of files grouped together in a bundle called a container image. This container image is really just a “fancy file” that has other files in it. When a container is started, the container runtime unpacks the files in the container image and hands them to the operating system. The operating system is then responsible for running the container and connecting it to a copy of the files from the container image. The operating system (more specifically the kernel) also limits how much CPU and memory can be used. So, containers are just fancy files and fancy processes handled by the operating system in a slightly different way than regular programs.

Which leads to the final piece of technology we will discuss: the registry server. The registry server is really just a fancy file server that knows how to store these container images so that users can share and collaborate when they are building them.

Now, let’s talk about the format of these fancy files, because it’s important to your technology adoption. The Docker project image format has become very popular—so popular that the industry has created a standard called the Open Container Initiative (OCI). So, when we talk about these fancy files, we are really talking about standard OCI container images.

Having a standard image format guarantees portability between registry servers. This allows end users to focus on building and sharing their work, not worrying about compatibility problems. The OCI standard is becoming very popular because it provides an easy, standards-based way for users and vendors alike to build and share container images. OCI-compatible registry servers can be deployed on premise, in development environments and in the cloud, which makes it really easy to move applications between environments.

So, if it is really this simple, why all the confusion?

Well, it’s partially because of how fast the industry is moving with containers. There is so much great work happening in the open-source community, which makes it hard to keep up. It’s also because many companies are exploiting the rising interest in containers by applying the term too widely, and therefore creating confusion.

While these fancy files and fancy processes are a simplified way of looking at containers, it’s one that will help business and IT managers understand how containers are (and aren’t) similar to technologies already in use. It also provides a clarified understanding of the technology.

At the end of the day, containerization allows you to focus on your application. Containers give you a simplified way of packaging everything your application needs in a standardized container image. This includes the language runtimes and all of the dependent libraries. Beyond this, it is an operating system process that runs in a specific environment with some resource management around it. Containerization is completely an operating system technology using files and processes; it isn’t recreating the operating system, nor is it replacing it. Containers instead extend the operating system.

(Related: Docker now keeps “secrets”)

So, how does this actually benefit my organization?

Having an ecosystem of standards-based container images, registry servers, and container hosts to run these fancy processes is completely changing the way customers build and deploy applications. Whether they are homegrown or off-the-shelf, the end user gains a lot of flexibility and efficiency. From architects researching potentially useful software for their organizations to developers trying to get code into production, this container infrastructure speeds up overall productivity and lowers frustration. This in turn leads to faster deployment and more consistent delivery, both of which are key components to having more satisfied consumers.

The post Guest View: Why containers are really just fancy files and fancy processes appeared first on SD Times.

OCI was launched last summer as an initiative to address the challenges and fragmentation in the software container space by providing a common set of standards. That standards are designed to ensure containers can be used without being locked into specific infrastructures, cloud providers and tools.

(Related: Kontena and Packet partner to make containers easy for developers)

“Ultimately, we want to make sure that the original promise of containerization—portability, interoperability and agility—aren’t lost as we move to a world of applications built from multiple containers run using a diverse set of tools across a diverse set of infrastructures,” the OCI wrote on its website.

Version 1.0 of the standards is expected to define what software containers are, how containers can be used in a cross-platform way, provide a versioning schema, address dynamic container updates, and ensure base configuration compatibility and full life-cycle hooks. According to the OCI’s release process, it needs to put out at least three release candidates before it can declare a version 1.0. This will be the second release candidate for runtime, and the first for image.

In addition, the OCI announced two new tools projects associated with the runtime and image spec. The runtime tools project will provide tools for testing runtimes implemented on the OCI runtime spec, while the image tools project will test and validate for container images on the OCI image spec.

The post Open Container Initiative announces new tools and release candidates appeared first on SD Times.

Cigital addresses these trends in BSIMM7, the latest version of its software security measurement tool. BSIMM7 looks at the value of software security, as well as industry changes surrounding security practices. The model it uses also has data on what firms are doing to stay secure, as well as the efforts to demonstrate what the companies are doing right.

The BSIMM7 model has expanded to include the largest amount of companies in its eight years of addressing software security, said Gary McGraw, CTO of Cigital.

(Related: Microsoft announces new security capabilities)

The model now draws from 95 organizations in six areas: financial services, independent software vendors, cloud, healthcare, Internet of Things, and insurance. (The last two industries were added this year.)

Industries represented within those areas included telecommunications, security, retail and energy, and it covered companies like Aetna, Bank of America, EMC, JPMorgan Chase, Siemens, Target and Wells Fargo.

McGraw said that Cigital tracks many industries, but only reported the data when they have at least nine companies in an area. This way, Cigital can report the data without “outing” any particular firm, he said.

Last year, the BSIMM6 model introduced the healthcare industry to bolster the dataset and show other healthcare firms what’s at risk within their systems. During this time, Cigital found software security to be lagging here. While healthcare software security has improved lately, McGraw said it still has a way to go.

On the other hand, the insurance vertical is slightly more mature than healthcare, and firms that were not paying attention to software security are now trying to up their efforts, according to McGraw.

Just like healthcare, data breaches are a big security risk for insurance companies, said McGraw. As this industry goes through its own digital transformation, it will completely change it will operate, he said.

“You used to go into your local insurance agent once every long time, but now insurance companies are releasing apps, and they have mobile solutions,” said McGraw. “As they adopt these new technology, they need to be really careful [of vulnerabilities].”

The BSIMM7 model is based on observation, and it serves as a “measuring stick” for software security for product security teams or software security groups (SSGs), said McGraw. The BSIMM is meant for use by anyone responsible for creating and executing a software security initiative, but developers looking to gain more insight into software security can benefit from the report as well.

“We still have many more people to teach about software security and building security in,” said McGraw.

According to the report, 272,782 developers have been directly touched by the BSIMM. With new technologies like IoT and containers, McGraw said it’s up to the SSGs to teach developers how to implement security better as software changes.

“That’s the job of the SSG, it’s to teach developers how to build security better,” said McGraw. “And that’s what we do at Cigital all day, we teach armies of developers how to code better, how to review their code with modern tools, what they can do when transporting their code to the cloud, and how to design and architect their code to be secure. All of those things are described by the BSIMM.”

The post Cigital’s BSIMM7 finds new industries taking on security challenges appeared first on SD Times.