BPOS: A Name Only Its Mother Could Love
*This is the third article in a continuation of our weekly series celebrating the 10-year anniversary of Office 365; In Part 2 Paul Robichaux details his experiences with the advent of cloud voice.
Before the launch of Office 365, Microsoft’s online service was BPOS or the Business Productivity Online Suite. BPOS was coined in the Balmer years, which is why as a name it doesn’t exactly roll off the tongue. Based on Exchange 2007, BPOS managed to grow to a few million seats, and in my mind, demonstrated the feasibility of large-scale cloud Office services, that today (mostly), just work.
As with so many others working with Exchange, my personal journey started with Exchange 5.5. The directory used by Exchange 5.5 later served as the foundation for Active Directory, which may explain why Exchange 2000 was also known in my day as the first “killer application” to use Windows 2000’s Active Directory. This was done by extending the schema to save configuration data in a highly accessible and self-repairing repository.
Without appreciating why, the lessons I learnt about directories and LDAP, mail routing, this “new” thing called SMTP and so many other fundamental technologies, proved essential to the understanding of an entire world. In the on-premises world, Exchange opened the understanding to Active Directory, RBAC, clustering, storage, networking, DNS, load balancing, certificates, voice over IP via Unified Messaging, the list goes on.
While BPOS was growing up into Office 365, I increased my investment in understanding Exchange Server by joining the Microsoft Certified Master Program for Exchange 2010. Honestly, it was the hardest thing I have achieved in my professional career. The depth of understanding we gained in three weeks of training in Redmond was unsurpassed. For example, our first three days each consisted of 14-hour hours on SMTP. The same level of depth applied to absolutely every nuance we could imagine within the product. We quite literally wallowed in nuances of the Exchange 2010 sizing calculator and learnt how to deploy at scale using the Exchange Preferred Architecture.
Exchange 2013 followed with continued innovation, better clustering, Active-Active Database Availability Groups across datacenters, simplification of name spaces, etc. It was all good and I was happy to share my knowledge of Exchange with customers and the technical community.
Following Exchange into the Cloud
Exchange Hybrid evolved too, going from manual deployment in Exchange 2010 SP1 which required many manual steps, to the first wizard-based deployment in Exchange 2010 SP2.
My focus shifted incrementally from upgrading Exchange on-premises towards achieving a sustainable long term hybrid state and migrating workloads at scale. I swapped my outbalancing workshops for client rollout and Outlook upgrade workshops. I stopped memorizing URLs used for load balancing in favor of remembering what client functionality was enabled using Outlook 2010 Service Pack 2 with the required hotfixes to connect to Exchange Online.
My world shifted radically away from on-premises deployment, towards understanding how to create and maintain the adoption of the purely service-oriented nature, known as Exchange Online.
The lessons learnt from working with Exchange on-premises still hold true in many respects though. For example – collapsing Exchange Online Tenants is not radically different from collapsing Exchange forests. Retaining reliability on old messages using X500 addresses is a concept as old as Exchange itself, having its origins in the Exchange 5.5 world of X.400 based name spaces.
My world has changed significantly over the last 10 years, from 3-year adoption cycles increasing to quarterly updates, to then becoming “evergreen.” I live in a state of duality, with one foot in a de-emphasized on-premises landscape, and the other in the cloud where I must know how to adopt and gain the best possible performance with fewer dials to turn and parameters to adjust.
The on-premises world I invested in so significantly to build, enable, upgrade, and migrate towards, is now enabled by the ticking of an option in Office 365. Where does that leave me personally? Having grown up with the cloud and built several cloud services myself, my appreciation has grown for just how amazing the achievement and scale of Office 365 really is. Cloud scale also enables speed and agility, where it will take us from here who knows – but we can’t see where we’re headed next without knowing where we’ve come from.
Source Practical 365