You may have heard that Magento is the eCommerce platform you use if you’re serious about your business—and you’re serious about your business—so you’ve decided on Magento.
But do you know what you’re getting yourself into?
Magento is an incredibly powerful program. One blogger I read compared it to a Leatherman, because it had a tool for every use. I like to think of it more as one of those large universal remotes people used to buy that seemingly had a hundred programmable buttons that could control every media appliance in their house.
It can do just about anything if, and only if, you’re willing to dedicate the time and money to make it happen. Magento is great, it really is, but it’s also complex. Are you willing to spend the time to educate your clients (or are they savvy enough to teach themselves) how to use Magento’s incredibly powerful admin panel? If not, you might want to look at another solution.
Magento is an expert system. Much like the various Adobe products, such as Photoshop and Illustrator, it rewards expertise, but at the cost of a steep learning curve. It can be grueling initially, but with a little work it becomes a potent tool.
For your business, this translates into more expensive hosting (does spending $300 a month on AWS hosting scare you?), higher development costs, and more upfront time working to understand the administrative features, but once these hurdles are overcome, you have a platform that is infinitely expandable and scalable.
Because of Magento’s flexibility and ability to scale, your business will not outgrow Magento anytime soon, and if it does, you’ll be doing so much business, you’ll be successful enough to tackle the next stage in eCommerce evolution.
Magento is the leading eCommerce platform, with roughly 30% of the market.
Magento excels (and, in fact, may be basically the only option short of a custom-built web application) when you:
- Have a large, complex inventory.
- Need to model complex product types.
- Have relatively static content.
- Want to run multiple stores from a single CMS back-end.
- Need a super powerful and expandable admin panel.
Other great benefits include:
- Magento’s large user base and commercial backing means that it is actively developed and secure. Security updates are published regularly and in a timely manner.
- Magento also supports a huge variety of payment gateways.
- Magento extensions have been developed for everything from auctions to data import and export.
- Magento is SEO-friendly.
Magento is open-source and was specifically made for eCommerce. It’s a PHP framework loosely based on the Zend Framework and uses a MySQL database for storage. Its module templating system has a hierarchical folder structure, which allows developers and designers to override core and theme files without editing them and without breaking subsequent updates unnecessarily.
Its open-source history is both a blessing and a curse.
The Magento ecosystem likely wouldn’t exist without it, but it has also resulted in a large, complex codebase that’s sometimes poorly documented and often has confusingly named functions. Sometimes it feels like everything in Magento is an exception to a rule, and often modifications have to be made in many different files to implement a single feature change.
This is partially why professional Magento developers are expensive. They’ve put in the time, taken the classes, stepped through the code, earned the certificates–worked damn hard to understand and master the complex beast–and as such, they deserve and expect to be compensated fairly for their time and expertise.
Caching can be an issue with Magento.
Properly configured on a professional hosting solution, Magento is highly-scalable and can run blazingly fast. Poorly configured on an underpowered hosting provider will take ages to load even the simplest page though. Caching is the answer: PHP opcode caching, database back-end caching, and full-page caching.
Opcode caching is now pretty much standard with PHP, but you might need to update the
php.ini file to configure it. A Redis back-end cache is also a must. And if you want the absolute best performance, a full page cache, like Varnish, is highly recommended.
These requirements mean that you need a hosting solution that will support these features, and you need a development team that knows how to properly configure them. Magento won’t run well on discount hosting providers, like Bluehost and GoDaddy.
You’ll need to spring for an Amazon EC2 or Digital Ocean instance (or an instance from one of the Magento-specific managed hosting providers that has these features already configured).
And what’s with all these caches?
Generally speaking, a cache is a short-term storage buffer for data that’s been fetched from disk or computed.
It’s the computer’s way of saying: I went through all the trouble of fetching or generating this data, I might as well keep it around a little while in case anyone else needs it.
Since caches are typically in volatile memory, retrieving data from a cache is orders of magnitude faster than recomputing or reading from disk.
The different caches mentioned above work at different levels of abstraction in the framework.
The opcode cache works at the level of PHP code compilation and saves already compiled chunks of PHP code for later execution. A back-end cache for Magento is an improvement on the file caching system. To display a page, Magento has to chew through potentially hundreds of PHP and XML files. This is slow.
Often the page contents don’t change between requests. Because of this, when Magento renders a page, it saves the results in a file system cache.
This is faster than re-rendering the page. But disk reads are still relatively slow, so using Redis as an in-memory cache to store these rendered blocks and pages is much faster (and it can also be used to store session data).
The third cache I mentioned, Varnish, is a full-page cache.
It works completely separate from Magento (and typically is installed on a separate server). It’s a caching HTTP reverse proxy: It sits between your website and the world, saving entire pages and associating them with request URLs.
Caching sounds great, right? It is, but it also adds significant complexity.
Consider this. Now, you’ve added a Redis database to your server; you’ve updated and maintained your configuration files; and you’ve possibly added another server to host your Varnish full-page cache.
Further, what happens when a page changes content? How does the cache know not to send the cached result? Uh oh.
There are obviously solutions to this, called cache invalidation, but it does add another layer of thought, complexity and potential problems.
On top of this, if your development team is truly professional, they’re going to insist on a test environment in addition to the production environment as well as a Git repository on GitHub for source control (and by the way, if they’re not using source control, find another developer!).
An alternative is WordPress WooCommerce.
It’s helpful to compare Magento with one of it’s main alternatives: WordPress with the WooCommerce plugin installed.
I recently worked with a company in Denver that had a fantastic Magento website and hosting solution. They had an Amazon EC2 instance for the production server, as well as one for their test environment. I was brought in to improve performance and help them implement a complete redesign of the website.
I set them up with a Redis back-end cache, which made the page load almost instantaneously, and worked with the designer to turn his Photoshop mockups into a live website.
After a few weeks of work, the website looked great. However, as I continued to work with them, I began to realize that the hosting costs and development costs were out of line with what they could afford.
As their branding evolved, they wanted to make more changes to the website, as well as integrate a number of custom modules. They were paying me thousands of dollars to help design, and redesign the website. Furthermore, at the time, they only had around six products. On top of that, they asked me about creating dynamic content and setting up a blog on the website.
Looking at their needs, the stage the company was in, and how much they were paying for hosting and development, we decided that Magento was not a great fit for them.
After a lot of research, they went with a new WordPress/WooCommerce website.
I essentially talked myself out of a job, but my priority was what was best for my client; and the truth is, if the client doesn’t know what they’re in for with Magento, doesn’t actually need its features, and doesn’t have the budget to support it, it’s not going to be fun for anybody involved.
If you have a business with relatively few products that fit into a standard business product model, WordPress/WooCommerce might be a great option.
WordPress developers are (generally) cheaper than Magento developers. The WordPress community is thriving, and the platform is very well-documented with a polished codebase. This solution is small, fast, and runs on pretty much any hosting provider, including all of the various discount providers.
If this combination will work for you, it will save you money in both development and hosting costs. If you’re trying to do your site yourself, without paying an outside developer, you should probably avoid Magento and might want to consider WordPress/WooCommerce.
Another reason you might look into WordPress/WooCommerce is if you want to take advantage of WordPress’s blogging capabilities. Magento has the ability to allow clients to create and update dynamic content, but it’s nowhere near as polished and as easy as it is with WordPress.
That said, WordPress/WooCommerce doesn’t have anywhere near the ability of Magento to configure products and discounts and manage large inventories (not that it can’t do it–it has great features and is growing constantly–but this is where Magento excels).
WordPress/WooCommerce will start to feel clunky when the number of products you sell grows past a few hundred, or when you start wanting to create complex, grouped products with custom attached attributes; or when you want to schedule discounts and give out rebates, but just to certain customer groups, and you want to cross-sell and up-sell and have a gift option; etc.
Which solution is right for you? It depends.
As is true with all technologies, Magento has a number of distinct advantages, but it also has its drawbacks.
Key benefits of Magento include:
- Open-source
- Specifically made for eCommerce
- Great discount system
- Payment gateway integration is easy
- Flexible and customizable
- Very powerful admin panel
- Highly scalable
- Once optimized (vanish, db optimizations, redis caching, opcode caching), Magento can be quite fast
- Multi-tenant support
- SEO-friendly
- Large user base, actively developed, secure
Known issues include:
- History of open-source has left it with an enormous, overgrown codebase that does everything, and leaves every door open to customization
- Not as well-documented as other platforms
- Development is expensive. Partly because it’s hard, and partly because it’s a popular system
- Important features are often only available in commercial modules of varying quality that may even require third-party integration support
- Expensive server requirements
All of these factors need to be carefully weighed on a case-by-case basis when deciding whether Magento is the right solution for you or your client.
Don’t be scared of Magento.
Have I scared you off of Magento yet? I hope not.
Does the following sound like you?
You have a thriving store with 2,000 products and need the ability to create complex configurable products with a dozen options and bundle those products with other products into groups.
You also want to be able to easily schedule sales and promos and hand out codes to clients for discounts. You have the budget and drive to invest in a truly professional solution that is open-source, SEO-friendly, highly scalable, and quite fast once optimized and properly hosted.
If so, take a look at Magento. If you’re willing to invest the time and money, it’s a truly professional eCommerce solution that will last a lifetime.
No comments:
Post a Comment