I recently posted a crib sheet of VMware’s product offerings for my own personal use.
In a similar vein, but with much more helpful detail, IBM’s cloud solutions team recently published a thorough VMware on IBM cloud reference architecture that provides details on the implementation of a variety of VMware’s virtualization offerings in the IBM SoftLayer cloud.
I recently witnessed this section heading in a lengthy document:
In context the section title makes perfect sense, and the number sequence is aesthetically quite pleasing. (I confess I searched, in vain, for section 3.2.1 “Contact.”) Yet I still had the feeling of non QED.
Yesterday IBM announced the new Bluemix Local System, the third generation successor to our Intel-based PureApplication System. There are three exciting new developments here:
I’m very proud of our team’s accomplishment in delivering the Bluemix Local System!
For my own benefit, I spent some time summarizing VMware’s product family as it stands today:
Software developers are too quick, I think, to blame unexplained bugs on a random memory overlay.
By the same token, hardware folks are, I think, too quick to blame gremlins.
However, after seeing incontrovertible evidence, I had to beg our lab team’s forgiveness the other day for having doubted them:
When I visited IBM customers and business partners in Bangkok and Manila last week, many of our conversations revolved around high availability and disaster recovery.
I previously contributed to an IBM Redbook on high availability and disaster recovery in PureApplication System that you can refer to as a resource. But now I’ve also completed a new overview presentation on implementing high availability and disaster recovery in PureApplication System. This presentation provides some background on HA and DR best practices in PureApplication System, summarizes the PureApplication features that serve as HA and DR building blocks, identifies a number of topologies that you can build using these building blocks, and closes with some important detailed considerations.
I hope you find this helpful as you design, implement, and test your solution!
Last week I spent time in Bangkok and Manila with the IBM PureApplication local teams and with IBM’s customers and business partners. It’s exciting to see continued growth in production workloads running on PureApplication System in ASEAN.
There were two repeated themes to many of our conversations. First was the importance of PureApplication’s pattern technology for building a DevOps pipeline that allows application and infrastructure teams to build greater confidence in the handoff from team to team between QA and production. Second was the strong interest in building high availability or disaster recovery solutions using PureApplication System. PureApplication provides many building blocks, such as GPFS and disk replication, that can serve as foundations for building HA and DR solutions.
See also: PureApplication High Availability and Disaster Recovery
I find in the age of corporate single sign-on and the multiplication of web applications and services, that more and more frequently I am running into server-side limits on cookie size. All of these servers and services are polluting my browser with their cookie crumbs. This results in web applications returning a 400 error due to header or cookie size limits.
While many web applications are beyond my control, I am taking the time to adjust my own servers so that they can accommodate these growing cookies. For nginx I’ve made the following adjustment to the server clause in my nginx configuration:
server {
large_client_header_buffers 8 64k;
client_header_buffer_size 64k;
. . .
}
full◦valence 