Link: Oracle plans to end Java serialization, but that’s not the end of the story

‘Oracle’s chief architect, Mark Reinhold, shared his thoughts about Java’s serialization mechanism which he called a “horrible mistake” and a virtually endless source of security vulnerabilities. This is evident in nearly half of the vulnerabilities that have been patched in the JDK in the last 2 years are related to serialization. Serialization security issues have also plagued almost every software vendor including Apache, Oracle, Pivotal, Cisco, McAfee, HP, Adobe, VMWare, Samsung, and others.’
Original source: Oracle plans to end Java serialization, but that’s not the end of the story

Link: Toxic Technology: the growing legacy threat

“The UK Government Digital Service recently wrote about how they understand legacy and suggested a number of factors that contribute to technology being considered legacy: being poorly supported, hard to update, poorly documented, non-compliant or inefficient. The range of breadth of these negative characteristics runs counter to an often passive view of legacy: stable historic technology that is intended to be replaced. Organisations should begin to think of this technology as toxic: actively harmful to the health of the organisation.”
Original source: Toxic Technology: the growing legacy threat

Link: IBM Drops Cloud Management Platform Onto Kubernetes

“The CMS platform is used by organizations to manage enterprise applications. Those applications include offerings from SAP and Oracle. CMS includes security, disaster recovery, automated infrastructure, and application management…. IBM launched its Cloud Private service last November. It’s built on a Kubernetes-based container architecture that supports integration and portability of workloads between the cloud environment and management across multiple clouds. This includes IBM Cloud, IBM PowerVC, Amazon Web Services (AWS), Microsoft Azure, and VMware on and off premises.”

Original source: IBM Drops Cloud Management Platform Onto Kubernetes

Link: Serverless at Bustle

‘Probably the biggest is: how do you deal with the migration of legacy things? At Bustle we ended up mostly re-architecting our entire platform around serverless, and so that’s one option, but certainly not available to everybody. But even then, the first time we launched a serverless service, we brought down all of our Redis instances — because Lambda spun up all these containers and we hit connection limits that you would never expect to hit in a normal app.

‘So if you’ve got something sitting on a mainframe somewhere that is used to only having 20 connections and then you moved over some upstream service to Lambda and suddenly it has 10,000 connections instead of 20. You’ve got a problem. If you’ve bought into service-oriented architecture as a whole over the last four or five years, then you might have a better time, because you can say “Well, all these things do is talk to each other via an API, so we can replace a single service with serverless functions.”’
Original source: Serverless at Bustle