Amazon in the Federal space? Absolutely!
I work for Quest Software, and focus on making sure that we are helping our Federal customers. So when one of our account managers asked me to me with Amazon, I was a little skeptical. Amazon? Really? I mean, I know the Feds have the "Cloud-First" initiative, and there are some things here and there, but can we really work with Amazon? What can we do with an organization that doesn't do anything with most of the platforms we support?
There's no Oracle, no Microsoft, PeopleSoft, SAP and so on. They don't even offer email that we can migrate to or from.
Well, it was an hour and a half well spent, and I am absolutely jazzed about some of the things we discussed. It turns out they are very, very serious about Security (with a capital S). In the Fed space, that is the number one objection to anything Cloud related. But they not only went through some of the certs and reviews they'd had (even a SAS 70 audit, which I think pretty highly of, having been involved in one years back) but their overall architecture and philosophy. They are keenly aware of the federal requirements that are out there, and have made a substantial commitment to making sure that their federal customers are able to use their solutions
Yes, they had an outage last week, but if you have concerns about these things, you should talk to Amazon about what can be done to prevent it. The outage was Amazon's fault, but there's also options (that obviously cost) which could be implemented to avoid such a thing happening. You can find a lot more info on the outage here.
In any case, it turns out they have a lot of options, including all the way down to a VPN secured environment, if that is your requirement. And because everything is web-based, and often accessible via web services, I think there are a few solutions that Quest have that could be used with Amazon's platforms. The conversation ranged from monitoring, to management and provisioning of resources, as well as integration with internal systems, and potentially even things like SSO and access controls. Lou J (the Quest Account Manager) even learned about Cloudbursting.
I hope to explore those options in the coming months, especially with some specific Federal customers in mind.
The Federal CIO’s guide to partnering with Quest Software for Data Center Consolidation, Part III
Note 1: the bulk of this blog post was done on an Apple iPad - I point this out not because of a fascination with the iPad, but because of the fact that such long documents were not readily possible from a mobile platform only a few years ago. That still amazes me.
Note 2: this is a very rough, stream of consciousness blog entry. Grammar, spelling and other writing errors should be ignored. If you want a nice, clean "white paper" type of document, please contact me offline, and I'll get you something cold and clinical.
------------------
Preparation and migration
--
Preparing for the move, beyond the simple assessment seems a no-brainer. But a migration? Really? Right before a move? And I say "yes." First, let's be clear and qualify that "migration" (to me) means a cut over to another platform. This could be email, user directory, database, etc, and it may be to a new version of some current software, but it's definitely getting off the current version. The idea is to make the software and version of that software as current as possible before you actually move to a new location/environment. The only thing this excludes is the move from physical to virtual. That comes later, and I'll explain why then.
There are several reasons for you to consider doing a migration before consolidating environments. First, and foremost, the migration is going to happen sooner or later, and aren't you better off doing the migration in a comfortable and stable environment instead of your new one? Plus, the migration may actually shake some things out and make the consolidation easier. For example, if you use QMM to migrate mailboxes from an old version of Exchange to 2010, or use QMM for AD to restructure your Active Directory environments, you may actually find that there are many users, mailboxes, groups and other objects that could be deleted/abandoned.
The same goes for databases. If you're running an old version of Oracle for your databases, it's time to cut over, and see what features and benefits you get. And we even have a tool that let's you mix versions to replicate data while you make this sort of move, so it's not a jarring, "all at once" process. That tool, BTW, is Shareplex. And it also let's you replicate mixed versions of databases, which is pretty cool.
But why else should you do the migration before starting the actual move? Well, frankly, because support is easier. Sure, you can migrate a Windows 2003 server, or an Oracle 9i database into your new environment, but if there's a problem, what will the vendor tell your team? Most likely, they'll tell you to upgrade to the latest version.
It's not widely discussed, but the reality is that most software companies want you on the latest and greatest version of their software when you call support. It's usually the version their developers are currently using as the basis for the next release. It's the version that support is working with most, and one that they have set up locally to recreate your problems. One or two versions is often ok, but if you're running something more than 2-3 years old, I think you're asking for trouble. Get to the latest versions however you can, because you don't want to consolidate and move old software around.
Another reason is your staff's personal development. I've run IT groups in the past, and the most common question was always, "when are we going to get to the latest version of X?" where X was some database, operating system or programming language. If you are the CIO at a federal agency, your staff knows that data center consolidation is coming, in some form or fashion. You want them ready and energized for the task. Letting them get to the latest version of whatever software they work with will excite them, and you'll have a happy crew moving into the consolidation.
Now, I did mention that cutting over to a virtual environment should be last. The reason is that this is really the same as a hardware move. No matter what hardware your environment is using, something is sure to change. And your software may react adversely. Plus, if you couple that with a version upgrade, you are changing a lot out from under your user base as well as IT staff. The idea is to minimize risk, and that just doesn't cut it. So do the "migration" first, get it settled, and then cut over hardware (which can be P2P or P2V).
And if you're contemplating a P2V move, you should definitely check out vConverter. Not only does it work with P2V, but V2V (you may want to switch hypervisors, or try out multiple hypervisors with the same ), and even V2P in case you absolutely have to back out. Or even want to switch hardware, using the move to virtual as a stepping stone.
Finally, if you upgrade, migrate and virtualize in a single move, how do you know where you got performance gains or losses? If you read my last post on this topic, you'll know I propose baselining before starting. The only way to do that is to start with a known point, but then make incremental moves so you can collect more information on what impact each part of the upgrade, migration and consolidation has on your environment.
The Federal CIO’s guide to partnering with Quest Software for Data Center Consolidation, Part II
Note 1: the bulk of this blog post was done on an Apple iPad - I point this out not because of a fascination with the iPad, but because of the fact that such long documents were not readily possible from a mobile platform only a few years ago. That still amazes me.
Note 2: this is a very rough, stream of consciousness blog entry. Grammar, spelling and other writing errors should be ignored. If you want a nice, clean "white paper" type of document, please contact me offline, and I'll get you something cold and clinical.
------------------
Initial assessment and baselining
--
Let's dive right in and get started.
To begin, an assessment needs to be performed to determine all the things that will be part of the consolidation. Presumably, this has already started as an initial plan is due to be submitted to the OMB for review and budgeting. However, everyone knows adjustments can and will be made. So I'd suggest you do an assessment assuming every item will be questioned.
There are lots of ways to survey what you have, but looking to Quest to help with that may not be something you thought to do. Well, you should. The reason is that we have a lot of tools, and lots of tools to help with your entire environment. From the operating system, to the databases and file servers, all the way to app and web servers as well as desktops. And while we're not in the inventory management business, we can certainly hold our own if you need a list.
"What kind of lists can you provide," you ask? For starters, we can get you users and desktops. Nowadays, most users are in Active Directory. And most of their desktops and laptops are joined to AD. So you could use something as simple as Quest Reporter to pull a list of those objects out of AD. Following the 80/20 rule, that should give you a good ballpark of your end-user environment. Need something s little more accurate? Then you'll need to do more work but get more results. You can either go with something like Desktop Authority to get you a good idea of what is actually out at the desktop level. Or, you can fall back to your AD event logs, and monitor login events over some time period with Quest Change Auditor for AD. In both cases, the products are sure to give you a lot more benefits beyond the initial assessment. And both Change Auditor and Reporter give you a good feel for your Windows server environment as well.
But the assessment is more than just a 'survey.' You cannot just make a nice clean inventory of everything you are responsible for, and leave it at that. It is critical to know -how- those systems are performing. In other words, you need to set a baseline, and you probably need to do it in 2 ways. The first way is through some measurements and metrics. Quest's Foglight platform is fantastic for end to end monitoring, and it can serve double duty by providing those initial statistics up and down your entire app stack.
Foglight can also provide those initial lists I mention above. You need RAM, CPU and disk numbers off your servers? We can get those to you, and help with some capacity planning as well. And if you run Foglight long enough, you'll have some very good trending and usage data to use beyond the consolidation effort.
The second baseline to check is subjective, and it's the user's perception of the current systems. This wouldn't involve any Quest product, but to simply put together a quick, 5 minute survey of what the users think of the apps they use. There are many free and paid sites out there that can run such a survey for you but I'd really encourage you to get this initial feedback. And if it starts to look grim, and you're surprised by the results, check out Quest End User Monitor to walk through the apps, and see what the users are complaining about.
That's really it on the baseline side. We can help with that initial assessment as well as providing initial metrics for how your environment is functioning. Can we provide complete coverage of your environment? Probably not, but the tools you'd use from us would continue to provide value beyond the assessment rather than being a throw away once the assessment is complete. And wouldn't it be nice to be in a new environment but with a familiar toolset? I think your IT staff would say, "yes."
The Federal CIO’s guide to partnering with Quest Software for Data Center Consolidation, Part I
[Note 1: the bulk of this blog post was done on an Apple iPad - I point this out not because of a fascination with the iPad, but because of the fact that such long documents were not readily possible from a mobile platform only a few years ago. That still amazes me.]
[Note 2: this is a very rough, stream of consciousness blog entry. Grammar, spelling and other writing errors should be ignored. If you want a nice, clean "white paper" type of document, please contact me offline, and I'll get you something cold and clinical.]
The current administration has developed the Federal Data Center Consolidation Initiative (FDCCI) with every agency and department falling under scrutiny. It is mandated by administration as a way to cut costs as well as secure the environment. This document does not seek to go into detail about the FDCCI but outline how Quest software can help every agency and department with the overall initiative.
The focus of the initiative is on physically collapsing all centers to a much fewer number. Of course, this is not just an exercise in put all the servers into a single room. This is an opportunity to both consolidate, and update the environment as well as potentially modernize key systems and platforms. And this is where Quest can help.
At a high level, the entire consolidation will involve the following steps:
- An assessment of the current environment, determining the disposition of every item to be included or excluded from the consolidation
- As part of the assessment, it is good to determine and establish baselines for services
- Prep work to get platforms or systems ready to be moved to their new environment - this includes any procurement and training that needs to occur
- The actual movement itself, which may be as simple as putting the same server into a new location or as complicated as migrating to an entirely new system on new hardware, operating system, platform, etc
- Tuning and optimization of the systems to their new environment
- Post-mortem review and on-going monitoring and maintenance
Depending on the agency or department, the age and condition of the systems, the number of users and administrators involved and the number of data centers, the time for each step will vary.
In all of this, personnel will also be affected. Not only may IT staff have a new location to go to, but they will also need new skills and tools. And with this, it would be good practice to audit and adjust access controls to make sure additional rights are not unduly granted.
Over the next few weeks, as time permits, I will be exploring the different areas of this sort of project, and tying it back to solutions that Quest Software provides. The hope is to give a good, solid overview of the help available from Quest in making this move. Many of the topics covered will also apply to other situations, and later on, I'll make the case that many of our solutions are "dual purpose" meaning they may be used by one set of users for a particular task, but that a different set of users may also benefit from the same tools in a different capacity.
First off, it would be helpful to review what Quest's goals are in providing the software that they write. At a high level, Quest is a systems management company. We do not have many of the platforms that people traditionally think of when they think of an enterprise software company; databases, web servers, operating systems, etc. For example, no one needs another database platform, at least not from us. But organizations do need to get a better handle on their existing databases, database servers, and the systems that use them. And that's where we come in.
We focus on making your existing infrastructure easier to use. This is not to say all our tools are simple. Yes, we have "Simplicity At Work" as our tagline, but we do some pretty complicated things. And while the overall message does make sense to someone familiar with the problems we solve, these are not "Fisher Price" tools. The common misconception is because we have some products that have the word 'wizard,' that they are easy. No, what it means we make whatever the wizard works against easier to use.
Lastly, it would probably be good to give you an idea of who I am and what I do. I am currently the CTO for Quest's Federal Public Sector group. Which means I keep an eye on all things Federal, working with clients and partners to help them get the most out of Quest while also working internally to make sure our solutions align with my customers' needs. We have many other people with similar roles, however I don't have a single area of focus. We have over 150 products, and anywhere from 3-8 different areas (depending on who you talk to). So I try and stay current with everything we have to offer.
And though I've worked with Public Sector clients since I arrived at Quest over 5 years ago, I've also worked for Quest in the UK as well as on the commercial side in North America. In those instances, my remit was Identity and Access Management as well as our overall Windows Management solutions. Before all that, and joining Quest, I was a developer, DBA, Director of IT, University instructor and a whole host of other things.
That's enough for now, and should give you a good enough idea of where this blog is headed over the next few weeks. If you have any questions or comments, don't hesitate to write me (dimikagi -at- federalcto.com) or post them up below.