Migrating to the cloud? Now is the perfect time to start or continue your digital transformation. There are several methods when it comes to cloud migration. At some point in your cloud journey you’re bound to encounter more than one of them and each of them certainly has its purpose.
But if you aren’t designing in the cloud, for the cloud (which could involve rearchitecting or procuring replacement application components), you’re missing out on many of the biggest advantages of cloud computing.
Here’s why “lift and shift” ends up stifling what could be a transformative cloud migration that sets the stage for your enterprise IT for years to come.
At Green House Data we like to say there’s no “one size fits all” cloud deployment. That’s why we don’t have base package pricing on the website — every VM is right-sized and designed around our client’s applications and business goals. That philosophy applies to every cloud deployment, and the network considerations aren’t exempt.
Depending on your objectives, the intended use of the application in question, and the location of your users and service providers, your network will have different performance and cost implications.
Let’s take a look at how to prepare your network for varying application deployments in the cloud.
Moving to the cloud, changing service providers, upgrading your host hardware, consolidating data centers, or switching to new software — they all might necessitate a database migration.
Moving a database is not a task to be taken lightly, but it can lead to more centralized and efficient management, lower storage costs, and/or reduced license requirements. To minimize your risk and downtime, follow these database migration tips.
The holidays are looming, meaning many DevOps teams are about to have their apps take a beating as hundreds of holiday orders and new device users slam them all at the same time. Whether or not your systems are consumer-focused, there will eventually come a time when the overall load on your servers is pushed to the limit.
Load testing applications in the cloud allows development and testing staff to perform scale testing to see at what point virtual machines need to scale, when to add additional resources like storage or bandwidth, and when a failover solution might be necessary.
By thoroughly performing load tests throughout the DevOps process, your organization eventually lowers costs and your team doesn’t have to scramble during a major event. Here are some best practices when performing cloud-based load testing.
With two different licensing models and several different versions of SQL Server, managing your licensing in a virtualized environment (like a hosted VMware cloud) is no simple matter.
This quick rundown will guide you towards the best licensing choice for your cloud VMs running Microsoft SQL Server.
Moving to Office 365? The user experience is bound to shift, with one of the biggest changes coming to the login process.
Each workstation might previously have had Office software installed locally, so once users signed in, they were free to launch and work on Word or answer e-mails in Outlook. With Office 365, you’ll have to configure user identity settings in a specific way to replicate this — or you can go the cloud-only route and have them sign-in again online in order to access these programs.
Here are some of the factors you’ll have to consider when setting up user identity management in Office 365.
While designing a new application may be the hot development path right now, enterprise organizations have a multitude of legacy applications that should not be ignored when undertaking a cloud initiative.
If you’re preparing to migrate some or all of your applications to a cloud environment, you’ll need to examine them and determine which of these four categories they fall under. With careful planning and perhaps some investment in development, your applications will work just as well in the cloud as they did on-premise.
Allowing your users administrative rights under their Windows desktop certainly makes their life easier, but it can cause significant headaches for your sysadmins — and it also opens up a wide variety of vulnerabilities.
A recent study from security vendor Avecto found that 94% of critical vulnerabilities announced by Microsoft could be mitigated by simply removing administrative rights. These vulnerabilities range from phishing attacks that can hijack the system via applications like Microsoft Word to packets that are specially crafted to hit Windows Server. In most cases, they can be leveraged to remotely execute code and take control of the PC, potentially accessing sensitive data and applications deeper within the network.
Many modern workplaces allow users more leeway over the configuration of their workstations, as computer-savvy employees are often more productive when they have applications set up the way they want. But with shutting down admin rights proving to be a relatively easy and strong method of eliminating vulnerabilities, should you risk enabling them?
The answer is probably not...with some caveats.
It’s impossible to imagine modern business without e-mail. While your users may scoff at the idea of a fax or hard line phone, in the background your IT department is working to make sure the e-mail systems your business relies upon continue to function smoothly, both in the moment of sending and receiving and for long term archive and retrieval.
A key element of a functional Exchange server is security. E-mail is an easy route for phishing, social engineering, and malware to enter your environment. It’s also a great way to access confidential information.
To maintain Exchange server security and the integrity of your business e-mail, follow this security checklist.
When designing the architecture for your SQL Server virtualized on VMware vSphere, your requirements will determine which SQL availability or vSphere availability features you should use. There are several availability features packaged with SQL server before you even get to vSphere features like Distributed Resource Scheduler, High Availability, Fault Tolerance, or vMotion, each of which have their own considerations when interacting with SQL.
To get started, you’ll want to ask yourself a few questions about your SQL deployment.