Update 01-13-2017: Wow! This posting got many good comments, also from Damian himself. I really appreciate all the comments and as promissed, I’ve updated my blog with the comments, including the names the persons who commented. All the comments are found at the end of this posting, in a table.
Why this posting?
Yesterday evening I attended the first WMUGNL webinar of 2017, titled Head to Head: Azure Pack and Azure Stack. In this webinar the presenter Damian Flynn talked about the differences between Windows Azure Pack (WAP) and Microsoft Azure Stack (MAS), and when to choose for WAP or MAS.
During the same presentation he stated multiple times that ‘SCOM is dead’. And that statement made me think. Is SCOM really dead right at this moment? Are WAP and MAS the nails in the coffin of SCOM? And why is SCOM dead? Has SCOM outlived it’s purpose? Or is there more to it, and needs it more perspective?
Time to investigate. Also because I highly respect Damian Flynn and knows that he just doesn’t say anything because it has a nice ring to it.
Some background information
In the days SCOM saw the light, the IT world was pretty well defined. All IT related hardware (compute, storage, networking) resided in one or more datacenters and was owned (or rented) by the ‘end user’, meaning the companies using it.
Cloud was still a buzz word and something not too many people really comprehended, nor didn’t suspect it to become what it is today (and still growing in size and capabilities).
Back to the datacenters. On top of all those IT ran all the other layers with on top the applications, processing the data for the end user, enabling them to run their business.
As such, monitoring was required and SCOM was one of those tools allowing IT departments to monitor all workloads, from the hardware up to the whole application chain.
The cloud is landing…
Maintaining a datacenter is quite a challenge, with life cycle management and so on. So a new type of datacenter was born, the Software Defined Datacenter (SDN). In the mean time the cloud was ‘landing’ in the IT shops. Excuse my pun, but what I mean is that step by step, companies started to see the advantages of ‘IT on demand’ enabled by the cloud. And IT departments had to follow suit, in order not to loose their (internal) customers AND to battle shadow IT. When you can’t beat them, join them!
As such WAP was born, allowing customers to build their own on-premise (better, in their datacenters) IT-as-a-Service offering, driven by System Center technologies, and connected to the public cloud, Azure. Not really a blessing since every single bit of the System Center stack is quite a challenge to master AND to maintain. But the power it delivers made a lot up for it. When combined it even becomes more of a challenge to proper maintain it.
Close but no cigar…
And yes, the Look & Feel of WAP felt like Azure (classic that is), but under the hood a whole different set of technologies was being used. Who ever thought that Microsoft uses System Center in their own datacenters, think again… One of the reasons being that not a single System Center component (except SCCM but that’s a breed of it’s own and NOT part of WAP) was ever architected to manage that kind of scale (thousands and thousands of servers, multiplied by their workloads).
Meaning, Azure and WAP were (and never will be) the same, making the connection between them a challenge to maintain AND to make full usage of it. As such, there was/is a serious disconnect between the two of them.
Say hello to Azure in your own datacenter
So it was time for another approach. Why not really extend Azure into your datacenter? Meaning Azure and it’s underlying technologies not only live in the public cloud, but also in your datacenter, allowing for a single consistent experience, usage AND management.
As such, not only the look & feel will be the same, but under the hood, the same technologies will run. Of course, not all Azure based services will run in your datacenter, but the ones that do will be the same. And is to be expected that the amount of Azure based services running in your datacenter will only grow in the time to come. Already MAS TP2 offers more services compared to MAS TP1.
And now witness the birth of MAS. Still in the making, but progressing to GA as we ‘speak’. But please, do not forget the delivery model of MAS. Where you can install WAP yourself and configure it, MAS comes pre-installed on server hardware from three different (for now) hardware vendors to choose from: Dell, HP or Lenovo.
And out of the box, MAS monitors itself. Meaning not the hardware (it’s to be expected that the vendors will deliver additional hardware/software for that), but the Azure based services making up MAS, are monitored in the same way as Azure is capable of monitoring itself.
In WAP SCOM is the monitoring tool, delivering insight from the hardware up to the application layer.
Back to todays world
So in the world of MAS, SCOM doesn’t play a role at all. Monitoring is delivered through other mechanisms, and also with a whole different philosophy behind it. Only when something is really broken AND you’re expected to be capable to fix it, you’ll be alerted. In other cases, you won’t be alerted but the vendor and/or Microsoft instead. Perhaps you’ll get a notification.
So in that respect, SCOM is dead. Or simply not present. However, one might discuss that whether the lack of presence equals death. But there is quite a catch here. More about that later on.
When looking at WAP, SCOM isn’t dead. SCOM is still part of it, and will deliver it’s monitoring functionality. However, when WAP is based on Windows Server 2016, some functionality in the past delivered by SCVMM and SCOM, is now ‘baked’ into Windows Server 2016 itself. The Failover Cluster has become a lot smarter and as such, far more capable of using the available resources in a smarter way. So in that respect the role SCOM plays is diminished.
Shifting roles
However, what is true monitoring? Meaning, do you want to know that server X or database server Y just stopped working? Or do you want to know that application flow X is impacted BECAUSE database server Y just stopped working?
Many IT shops (and their customers) choose the latter. Which makes perfect sense. And this is where SCOM comes in and still plays a significant role, especially in todays world where many workloads are hybrid, running partially on-premise and for the other part in the cloud.
Sure, MAS delivers monitoring but in a more siloed approach. Not the whole chain is covered, making up the business critical applications. And this is where additional monitoring is required. Either delivered by SCOM or other tools, perhaps OMS. However, the latter has made itself rather unpopular with the new licensing model. Besides being unclear, the costs have grown significantly.
So when already having a SCOM environment in place, it’s easier to extend the monitoring footprint so it covers the hybrid business critical application(s) as well.
Perspective
So time for the recap. First an overview.
SCOM is lacking presence (feel free to translate it to ‘dead’) when:
-
Running MAS and monitoring is only targeted at the silo’s (compute, storage, networking, platform, Web, SQL and so on);
-
Monitoring across all these silo’s, making up one ore more business critical applications, isn’t required;
-
MAS and Azure are the ‘only’ workloads and there is no on-premise SCOM environment at hand. In such a case I would strongly advise against a SCOM deployment, but advise for OMS instead. What’s lacking today will be there in the time to come, since the drive behind OMS is huge;
-
Running MAS and hardware monitoring is required. That ‘gap’ will be dealt with the vendor delivering MAS (Dell, HP or Lenovo) since the hosts running MAS won’t allow any ‘alien’ software by running lock down policies. All non-MAS software will be simply blacklisted.
SCOM is still alive and kicking when:
-
Running WAP combined with public cloud (Azure);
-
Running a hybrid environment (on-premise/private cloud/public cloud);
-
Monitoring across all the previous mentioned silo’s, making up one ore more business critical applications, is required;
-
Other applications are running on-premise only and require monitoring as well;
-
The company you’re working for is moving towards to the cloud, whether MAS or Azure based and while in transition, monitoring is required.
BUT don’t be sentimental:
-
SCOM is ‘old school’ technology, based on SCOM 2007 which saw the light in (duh!) 2007;
-
In 2007 the cloud was branded as a hype to be, a buzz word. Not many expected it to become the next big thing;
-
SCOM isn’t made for the cloud, it can’t encompass the sheer size and numbers;
-
New IT delivery models demand/require a new way of monitoring.
However:
-
System Center 2016 (and SCOM 2016 as such) has the Mainstream End Support Date set on the
11th of January 2022;
-
So until that date SCOM has still the support of Microsoft and will grow and develop further (within the previous mentioned borders);
-
Meaning ongoing investments in SCOM are still valid and do make sense;
-
SCOM still delivers monitoring capabilities yet lacking in OMS;
-
When already running SCOM it makes sense to upgrade to 2016;
-
When not running SCOM, think TWICE whether it’s worth the investment, or perhaps wiser to move on to OMS;
-
Make a decision based on the (monitoring) requirements and not because you want to implement the newest sexy thing.
Putting it all together:
Basically I am trying to say is that Damian Flynn didn’t talk rubbish but that it requires more perspective. I hope I’ve provided the (for me mostly) so much required perspective.
Feel free to comment on this posting and share your thoughts. When you provide your name AND your feedback is well founded, I’ll update my posting with your feedback AND your name.
Comments this posting got so far
As stated earlier, feel free to comment. Here are the comments this posting got so far. And of course a BIG thank YOU for taking time to comment. Much appreciated!
Just like Damian commented: ‘…This is why we have this amazing community, so that we can talk, share, learn and stir up Debates :)…’. Amen to that Damian!
Damian Flynn:
Thanks Marnix I sure did not want to stir up a storm to suggest that you need to drop any investments in SCOM, or even stop investing in SCOM; I am aware of a number of organizations whom are currently active in creating bespoke management pack, and will be in Stuttgart next week providing input on a commercial MP being developed for SCOM. So honestly that was not my intention My perspective, is aligned tightly with the brilliant perspective you have presented in this post; The plumbing on the new fabric for clouds build in Azure Stack or Open Stack is no longer dependent on foundations like System Centre; and its health, orchestration, and core functions have truly been reimagined. From that point SCOM is dead, but so to in that vein is VMM. However, In the spirit of the presentation, WAP 2016, is still a very powerful proposition; and its foundation is VMM, SCOM and SPF; and all 3 of these components are mandatory for a full deployment; in this perspective it’s a Long Live SCOM chant. The middle Ground however is that if you want, or need to maintain that single pain of glass view of your environment, and your chosen product to deliver this is powered by SCOM; then even if you are going to adopt MAS or OpenStack as your new Cloud Platform; all that will be required is a new Management Pack; which will communicate directly with the Health Services of these platforms. And of course, we have ignored Application Insights, and OMS; neither of which are on any road map I am aware of to be moved on premise. Or, if you are working in an Air Gapped environment, where online; or Hybrid are not options to consider; then again we will be quite happy to have good support until mid-2022 with SCOM.. As I mentioned in the webinar, there are a LOT of moving parts now, and the choices for what cloud platform is no longer a simple A, B, C or D decision. As we highlighted with the Migration from VMM 2012 to VMM 2016; this challenge also stands true for SCOM also. Identify the correct sequence, understand what works and what will not, what is continued in the support matrix, and what is no longer considered supportable... This is why we have this amazing community, so that we can talk, share, learn and stir up Debates :) It’s all opinions.
Best Regards
Damian |
Wilson328:
When it comes to the future of SCOM, I think we also need to look at Microsoft's actions. From what I can see, SCOM2016 is a very incremental upgrade....more akin to an R2 release than a whole new version. Compare that to the rate of innovation and development of OMS in the same time frame and it becomes clear where Microsoft is devoting their engineering resources. Microsoft also has a financial motive. If you notice, OMS was originally part of the System Center Suite but was taken out. Most companies are licensed for the entire System Center suite as part of Software Assurance licensing. But OMS requires a separate add-on license so it provides them with an additional revenue stream, Also, look at what happened with the Bluestripe acquisition. Instead of integrating that topology-mapping technology into SCOM they instead put it into OMS. As far as I know there are no plans to incorporate the Bluestripe technology into SCOM. That to me is the biggest disappointment and tells me that any further improvements to SCOM will be of an incremental nature while products like OMS continue to see rapid development and innovation and will start overlapping more and more with SCOM's core strengths.
|
).
), it turns out that SCOM 2016 UR#1 runs great with SQL Server 2012 SP3 as backend! Therefore Microsoft is in the process updating the related documentation.
