Adobe Commerce Reviews

What is most valuable?

For how long have I used the solution?

Amazon Web Services (AWS) is the most popular and robust Cloud Hosting Infrastructure. Millions of sites and some of Internet’s most popular sites, portals and eCommerce Sites run on Amazon.

Deploying Magento Enterprise on AWS for serving millions of users and a large catalog size would require a deeper understanding of Magento and AWS.

This article talks about the architecture and points to consider while deploying Magento Enterprise on AWS.

The diagram below shows a recommended minimum architecture to deploy Magento for High Concurrent Traffic.

Given the architecture above the following points / settings  need to be considered while setting up the servers

1. Make your App Servers Stateless:
   What this essentially means is ensure that none of the user specific information like sessions, shopping bag contents etc are not stored on the server. The sessions storage must be moved to the DB or Memcache. This will allow you to easily add or remove an app server, without the online users getting logged out out or losing their shopping basket contents.
2. Do not enable sticky sessions on the Load Balancer:
   A load balancer is usually programmed to re-direct users to the app servers on a round robin method. However if sticky sessions are enabled then the load balancer will direct all traffic from one user to that one single server where his session is created.  While this works fine in most cases, there could be scenarios where the users connected to one server would be more active than the ones on the other, this would lead to an overload of one server while the other is relatively low on load. This would obviously affect the response times for users connected on the loaded server.
3. Ensure that the Media Folder is stored in an S3 bucket and it served via Cloud Front.
   I’ve seen many deployments where the media folder, which contains all the product images and other static content is being duplicated across the multiple app servers and is being rsynched each time a change happens. This is not ideal as the replication take times and while users would be able to see the images, the other would not be able to. The ideal way is to have the media folder on a S3 bucket and have it served via Cloud Front  (CDN) so that the images are served from the nearest node.
4. Put your CSS and JS also on CloudFront:
   Well that’s a no brainer,  all static content should be served out of cloudfront. Don’t forget to concatenate, merge and minify the JS and CSS files. Magento is notorious to have 12-16 different JS files. in their default and Enterprise themes.
5. Enable IOPS for your RDS database:
   Relational Database Service  (RDS) is usually the most preferred way to get your MySQL on AWS. RDS will make it really easy for you to get your database in Master Slave mode, and schedule automated data backups. However RDS can turn out to be a bottle neck when it comes to high read writes to the DB which Magento does a lot. This is because the RDS is essentially stored on a SAN which comes with its own latency problems. The one way to overcome that is to enable IOPS for RDS to make sure the app servers can read and write data to the RDS database sufficiently fast.
6. CPU over RAM:
   Magento users a lot more CPU than it uses RAM, so while choosing an Instance try and go for one that gives you more CPU power than RAM.
7. Use Memcache:
   User a Memcache server this will significantly improve the sites performance. Also importantly ensure you have a bank of memcache servers running and have it properly configured in Magento, else your memecache server can become a single point of failure.
8. Use Nginix instead of Apache:
   During most of our load tests, we notice the web servers being overworked most of the time and using most of the CPU power. Nginx has a much smaller foot print as compared to Apache and can server a significantly higher number of concurrent users than Apache.
9. Varnish can be a double edged sword:
   Many architects think simply throwing in a reverse proxy  like varnish before the app servers will help boost performance, that’s quite wrong. Putting Varnish in front of Magento Enterprise with full page caches on can actually be counter productive especially if Varnish is configured to server only images and static content. In many scenarios its actually good not to use APC instead of Varnish to improve speeds.
10. Disable xDebug:
    xDebug comes default within the Magento Installation and is quite useful for debugging the application during development. However it will slow down the site while running in production mode.  Significant performance benefits can be achieved by disabling xDebug in Magento.

With the above configurations we’ve been able to have our Magento Enterprise Portals server 50+Million visitors with under 5 seconds of page load times during peak loads.

Disclaimer: The company I work for is partners with several vendors

With the recent feature rich releases of Magento Enterprise, there has been a groundswell of Magento customers that are shifting from Community to Enterprise.

In Magento’s early days – the gap between the community and enterprise products was narrow…but that is no longer the case.  New features, improved architecture, multi-storefront approaches, PCI, scale, speed – these are all areas that Magento has invested heavily in their Enterprise solution.

A large volume of merchants who have successfully grown their existing ecommerce business using Magento’s Community Edition have been confronted with the the need to improve their system scalability and features. as their online traffic increases.

In short, companies are quickly outgrowing the Community Edition.  Many Community edition users have been painfuly confronted with the realization that trying to customize Magento Community Edition to try to mimic enterprise through custom code and the use extensions doesn’t really save money over time and can in fact cost more.

So…for all of you looking to make the Community to Enterprise move…here’s how to do it.

In this review, we will share some of the key items to consider when planning for your upgrade and what to expect when executing your upgrade project.

Step 1: Perform a detailed assessment of your current environment.

Upgrading to Magento Enterprise from Community Edition does not have to be a difficult process. But to do this in a predictable, reliable manner, there are some very important facts you need to know before you start.

First, what version of Community Edition (CE) are you using?  If you are using version 1.5.0 or earlier, your upgrade is going to be more difficult. Architectural updates to the platforms beginning with the release of version 1.5.1 of CE will result in a multi-step upgrading process to resolve differences in the software stack.  If you are working with a partner to do this upgrade, make sure you provide this information and make sure you provider can provide you with a game plan of what to expect.

Second, identify and document which extensions or plug-ins you have installed on your CE instance.  For each extension installed, you’ll need to answer the following questions:

1. Is the extension you installed on CE required on EE or does EE offer similar functionality out of the box? For elements like coupons, pricing promotions, loyalty points, the answer is likely yes.  As a result, you will likely not carry the extensions over to the new site, but you will probably need some form of data migration to move the data from the extension’s table structures into the out of the box Enterprise Edition instances.
2. If the extension is not duplicated by out of the box EE functionality, is there an EE version available you can use?  Note, many extensions used on community edition are not supported on Enterprise Edition at all. In some cases, an EE version may exist, but you need to purchase a different version or license key and apply a new package that is compatible with EE.
   1. If you are going to be implementing an EE version of an extension, make sure the provider has documentation or can walk you through how to upgrade your CE version to EE version.
   2. If the extension is not duplicated by out of the box Magento EE functionality, and an EE version of the extension does not exist, you will need a plan and timeline to either update the extension’s code to work with EE or replace it with a custom built set of logic or functionality.

For step 1, plan on spending a day to catalog your extensions and at least one to two days reviewing the alternative solutions and building your plan to address items 1, 2 and 3.

Step 2: Check for Core file changes

Once you have cataloged your extensions lists and defined your areas of impact, the next thing you need to consider is whether you have made changes to the core Magento files (non upgrade safe changes).  Note, Magento’s architecture has a defined method for applying changes in an upgrade safe.  Your IT team member or services partner may want to consider taking a copy of your site, and a clean, unmodified version of Magento CE that you are using and do a ‘diff’ on the core file structures to see what has been changed, if anything.

If you have made core file changes, note, you will want to take a full back up of the changed files because there is a strong likelihood that the upgrade will overwrite some of these changes, if not all.

Make sure you comment the sections of code where you identified core changes.

*A note on integration work. Integrations are typically done in an upgrade safe way. However, you want to pay special attention at this point to document and backup any files you used to integrate Magento to any other system. These will be critical points of verification as you move forward.

Once the changes have been documented and backed up, move on to step 3.

Step 3: Plan for test and deployment

Start with the end in mind, plan for testing and deployment before you start your upgrade project work.

You don’t want to upgrade your production instance right away. In fact, you may not want totally upgrade your production instance at all, you may want the two instances running side by side for a time to give you a fallback option is something goes wrong.

So first, plan on how you will deploy your upgrade to production and where you will do you upgrade project and testing prior to launch.  We strongly recommend you setup a development site and server. This means having a separate physical host (or virtual server) that will not share resources with your production server. The upgrade process can be resource intensive – you don’t want to disrupt any production activity during this project.

Once you have your development / test server in place, take a full back up of your production site (code and database).  Deploy it to your development server, and keep a copy of the backup zipped up for reapplication if you need it. You don’t want to have to take multiple backups if you run into issues early on in the process.

With the development site in place, you’re now ready to plan for your acceptance testing.

It is a great practice to document your testing steps and expected results (an Excel Spreadsheet is fine) before you start work. Take screen shots so you can compare before and after results to make sure your logic changes work the same after the upgrade. Make sure you define all the key conditions you need to validate before you launch to production.

Also, make sure you test scripts include a means of validating that any integration interfaces you had in place still work properly. Integration is usually time consuming, and you don’t want to realize after you’ve deployed to production that you need to update this portion of your site post go live.

Trying to put this together after you’ve done your upgrade can be very difficult – so start with the end in mind.

Step 4: Execute the upgrade

Time to upgrade.

Based on your assessments in steps 1 and 2, you should begin applying the upgrade package and working through your plan for extension or core file change management.

If you are starting with version 1.5.1, the upgrade to the current version will be relatively quick (a day of effort to run through and do an initial validation of results) and painless. Reapplying extensions, core file changes or new logic will then occur and the effort for that will depend on the volume of changes you have to support. If you don’t have many extensions or any core file changes, this part may take as little as a few days.

If you have a large number of extensions, core file changes, etc, you could spend a few weeks going through this process.

**Note, critical success factor for managing time, budget and success.

We strong urge that customers NOT begin adding new functionality or features right away or as part of the upgrade process.  Moving to Magento Enterprise Edition will arm you with an entire new set of features and tools. You should strongly consider releasing the upgraded site first, let it bake in, learn about what you now have at your disposal, and then plan on what new features and functionality you want to add after your new site is in production and you are comfortable that everything is stable.

You will learn that Magento EE does more than you think. You’ll also learn that the approaches to adding new functionality change with EE and it is a much more flexible architecture.  – A little patience on this front will save you time and money overall.

Step 5: Test, Validate, Revise

Once you have what you consider to be an upgraded development instance, it’s time to execute your test plan. Go through and test with detail that the upgraded development site functions substantially the same as what you previously documented. Validate not only that it is error free, but that calculations, taxes, UI elements, etc. all match up.  Be sure to test any integration interfaces you had in place and that integration transactions work properly. Finally, make sure that any extensions you replaced, upgraded or removed work properly or that the intended revised functionality based on EE out of the box tools works as you expect it to.

When you can confidently say you have validated your existing, as is functionality is working properly, you are ready to plan for a move to EE in production.

Step 6: Plan for Go Live

To convert your in production site to EE, you’ll need to do one of two things:

1. Either plan for some minor downtime on the site (and have a site down for maintenance notice page in place ready to go) <or>
2. Stage a parallel EE Production site with the completed/ upgraded software in place and plan to cut over from one box to the other, realizing you may have a few straggling orders in the old site that either don’t show in the new site or need to be migrated over via a data migration.

When you do this, the biggest thing to realize is that if you are making DNS changes to point to a new host, those changes may take up to 24 hours to propagate nationwide or worldwide.

As a result, it’s a good idea in advance of your launch (at least 3 or 4 days in advance) to reduce the Time to Live (TTL) settings on your DNS entries to as low a value as possible so that the changes propagate as quickly as possible.

Even with a low TTL, some traffic will still route to the old IP address for a little while unless you’re firewall or network configuration has a rule in place to route to the new host internally.

Either way, plan to make the production move at the beginning of what is a low traffic period for you. Most people automatically assume this means weekends. For B2B oriented sites, that might be the case. But realistically, you should look at which days of the week (and times of day) have the lowest volume. It very well may be that a weekday in the morning is the best time to make the change.

When you plan your cutover, make sure that all necessary support, admin and customer service representatives are aware of the change so that if call volume to your office increases, they can give a clear message and that they are prepared for any spikes in activity.

Step 7: Plan for “Post Deployment” Support – you need a plan in place before you launch your live site

This is the one area that is constantly overlooked or undervalued. When you make any large change, you will find that something comes up post launch that you either didn’t anticipate or that you missed somewhere in your process.

If you are launching in off or late hours, your support staff will need to be calibrated to provide late hours support and probably be in early the next day in the event there is an issue to triage.

If you running a site with high volumes of traffic or orders, you, your support staff, and your IT team or partner need to have a plan in place for ongoing bursts of activity for at least the first week post launch.

Once you get through week 1 and all is calm, then it’s time to prepare for the next batch of new functionality you wish to implement.

Disclaimer: The company I work for is partners with several vendors

Magento is the world’s biggest ecommerce platform which has been chosen by over 200,000 retailers world-wide, ranging from small start-ups to the likes of Fred Perry, Harvey Nichols, Warby Parker and many more. You can find more examples of Magento websites in my Magento showcase blog post here.

Magento was only officially released in 2008 but it quickly gained traction and became one of the biggest open source ecommerce platforms on the market. In 2011, Magento was acquired by eBay.

There are three versions of Magento, there are:

-       Magento Enterprise – premium version which offers more functionality that adds value to enterprise-level retailers. This version of Magento is very expensive and is not necessarily the best option for mid-level retailers.

-       Magento Community – the free version of Magento, which is used by the majority of Magento users. Community has lots of great features and is suitable for most retailers.

-       Magento Go – Magento Go is their hosted solution, which is similar to popular platform, Shopify. Magento Go is more suited to smaller retailers but does allow for users to upgrade.

Magento’s Community and Enterprise editions also benefit from Magento Connect, which features thousands of free and paid third-party modules / extensions to provide additional functionality for stores.

Right, so you’ve read my introduction to the Magento platform, here are nine potential reasons to move to it. There’s every chance that I’ve missed some reasons here, particularly as I’m not a programmer – please feel free to add any others within the comments below.

Developer following

Possibly the biggest advantage of using Magento over other ecommerce platforms (especially premium ones), is the huge global developer following it has. This adds a lot of value as lots of common issues and errors are documented on various different forums and blogs, helping store owners to overcome issues without having to use a consultant / agency / contractor.

There’s also lots of developer resources / guides around online, as well as MagentoU and the Magento certifications, which cover lots of the Magento core and validate a developer’s ability.

Scalability

The community edition of Magento is highly scalable and is suitable for retailers of all sizes. With larger retailers based on the community edition, I’ve seen lots of the functionality from Enterprise implemented on Community, such as full-page caching.

There are retailers that are turning over £20m+ online using the community edition of Magento without having any reason to look to migrate or move onto the enterprise edition.

Smaller retailers who are using Magento Community can operate knowing that their platform will allow them to grow considerably without hindering them.

Because so many different solutions integrate well with Magento (such as Salesforce and various different EPOS systems), retailers can also grow with the help of third-party software that can be fully integrated with the platform.

Magento is / can be SEO-friendly

Although out of the box Magento isn’t particularly good for SEO (because of the amount of duplicate content – read my Magento SEO post for more info), it can easily be tamed with the help of third-party modules.

The basic elements of SEO are already covered with Magento, such as meta content, use of the canonical tag, top-level URLs, search-friendly URLs, redirecting functionality etc.

Open source code

One of the key benefits of using Magento over other platforms is that it’s open source, meaning, amongst other things, it’s more flexible for developers, it’s more accessible (in terms of cost) and it’s more secure.

Lots of developers and agencies

There are thousands of Magento developers and agencies all over the world, meaning that if you get burnt by an agency / developer and want to move away, you’ve got the option. This is one of the main reasons I’d use Magento, because there are so many good agencies out there with experience and you’re not tied to a single provider unless you sign a contract.

Lots of functionality and features

Magento is filled with all kinds of functionality out of the box and has everything you need to run a standard ecommerce shop. In addition to the obvious things you’d expect out of the box, you’ve got a flexible product catalogue (which can be built into a product feed), a Magento module to help you create a mobile app / website, gift code / card functionality and lots more!

Some other examples of Magento features:

• Built-in upselling / cross-selling functionality
• Configurable pricing
• Multi-store (can be ideal for internationalisation, managing multiple shops etc)
• Product bundles
• Newsletter management
• Customer groups
• CMS pages
• User management
• Advanced stock management
• Multiple image per product
• Advanced shipping method / supplier control

Magento Connect

Magento Connect is an extension marketplace that features thousands of modules for Magento Enterprise and Community. There are apps for anything from SEO and blogging to image handling and affiliate marketing. All of the apps have ratings and reviews, enabling you to decide whether to install or purchase one.

There are lots of good and bad extensions on Magento Connect, which you’ll get with most platforms, but they are vetted which helps to give the user piece of mind from a security perspective.

Different versions

I know I’ve already mentioned the different versions of Magento about 10 times in this post, but they’re very different and it’s key that you pick the right one.

Magento Go is relatively new and is designed for startups and small businesses who want a one-stop solution for ecommerce. Magento Go is a hosted solution and it has everything built in to allow you to sell products online.

Magento Community is a more robust platform that you will need to install and host yourself. One of my biggest recommendations for people starting out is don’t use Magento Community unless you know what you’re doing, far too many people make that mistake and end up in all kinds of trouble.

Good Magento developers are hard to find, but I’d suggest you need one to run a decent Magento store. If you’re in the UK and are looking for an agency or developer, you can drop me an email on paulrogers@gmail.com.

Magento Enterprise is a very expensive solution, but it’s well suited to large retailers. Examples of retailers who use Magento Enterprise include Dreams, Ford, The North Face, Harvey Nichols, Fred Perry and Paul Smith, although there are lots more.

When you’re paying for Magento Enterprise, you’re paying per server, so if you’re using multiple servers, be aware that the annual cost of additional servers is around $10,000 for each.

The fact that there are different versions of Magento for different sized retailers adds a lot of value in my opinion, as ecommerce platforms are not one size fits all.

Integrations

Hundreds of software providers integrate with Magento and there are also lots of great agencies who work on bespoke integrations too. The agency I used to work for (who are very good with Magento), GPMD, built the integrations for Locayta (a well know merchandising solution) and PayLater (a new payment solution).

Other examples of readily available integrations for Magento include PayPal, MailChimp, Campaign Monitor, SalesForce, Zendesk and many more.

http://www.paulnrogers.co.uk/9-reasons-to-use-or-migrate-to-magento

The Supercircuits website was running on an custom-developed ASP.Net ecommerce platform, which I inherited when I joined the company. Over time it had become increasingly unwieldy, hard to update, and buggy, and I was desperate to move on to a more modern ecommerce platform.

I'd been interested in Magento for a while as it appeared to meet all of our functional needs as well as being very affordable, and so, after a short period of due diligence, we embarked on an implementation of the Enterprise Edition.

Little did I know then, that it would take over a year to launch the site. But that's what happens when you combine a very small team, with a lot of operational responsibilities, with the requirement to integrate with an internal order management system that's about 10 years old.

Lesson learned #1: If you are about to embark on a major Magento implementation, I highly recommend making use of their consulting services at the outset. An architectural advisory will set you back a few thousand dollars but will make sure you pick the right architecture plan so that your implementation goes more smoothly. We did a lot of learning as we went, which slowed progress as you might expect.

Another challenging area was the migration of product data from the old site. Although we have a little under 1,000 SKUs, because they represent video surveillance equipment, they each have a lot technical specs along with various other complexities.

We had originally intended to manage product data programmatically via a centralized master data management system, but in the end, this proved too much to try and implement along with everything simply developing and launching the site.

As a result, we did not make proper use of attribute sets for classifying different product types, the results of which we are living with today (one day we will have the product comparison tool set up correctly). On reflection, we would have been better off entering all the product data manually and using the extra time to clean up the organization of our technical specs.

One area where we did make the right decision was not to attempt a complete site redesign at the same time. The relaunch was intended to be a "copy exact" — use the base Magento Enterprise store template and overlay our design on top of it. This worked pretty well, as the base Magento template looked nicer than our old site anyway, and we were able to make some further visual improvements in addition to this.

The good news is that we are now in a place were we can start making some more aggressive site design enhancements, now that the back-end heavy lifting has been completed.

A significant reason to move to Magento is its extensibility and the wide range of extensions that have been developed for it. If you can think of a feature, chances are someone has developed an extension for it. The great thing about this is that it reduces implementation time and cost for new features dramatically. I'm like a kid in a candy store with all the additional ecommerce capabilities that are now available to me.

Lesson learned #2: Not all extensions are created equally. I recommend limiting the number of extension vendors you use so that you can be confident in their quality and reduce the potential for code conflicts. We have mostly used extensions from aheadWorks and Amasty. Not only do they create great products, but the support of both vendors so far has been excellent.

Another reason I like Magento is that, as with Google Analytics and Wordpress, because the basic edition is open source it has a huge install base with lots of people developing for it, figuring things out, writing blogs and tutorials, and answering questions.

Consequently, if you have a question about or an issue with Magento, it's likely that someone has run into it and someone else has come up with a solution. The value of this wealth of information cannot be overstated.

One final downside of the extended development time for this website launch is that Magento Enterprise has moved on to version 1.12 while we are still on version 1.10. I do not intend to underestimate the effort to upgrade to the latest version, but it is something that we will need to tackle in the near future. If you don't, as you move further away from the current version, the cost and effort to upgrade just gets larger and more daunting.

A feature that we intend to take full advantage of over the months ahead is Magento's multi-store capability. At some point in the future I intend to have all of our sites running on the Magento platform which will be a huge efficiency gain for my team in terms of managing multiple websites and stores with a common product set.

One area where we have learned a lot is in regards to SEO. While we did all that we could in terms of onsite SEO, we (by we, I mean I) only redirected about 1500 URLs in our htaccess file. However, we have thousands of old product documentation PDFs which I did not have the time or will to get to before the launch which were still receiving links and traffic.

As I started seeing 404 errors pop up in Google Analytics for those pages and files, I began a multi-week process of updating the htaccess file, so that we now have over 6000 redirected URLs.

I am now keeping our htaccess file updated on a monthly basis by running the URLs being redirected to through Xenu's Link Sleuth, which lets you check an imported list of links (very handy). As redirected URLs break (for example, when products are discontinued and are removed from the site) I'm updating the redirect to keep it working. It's very manual, but worth it in my opinion.

We're now on a two-week release schedule for new features, which is aggressive but achievable. One module that we are replacing as soon as possible is our site search. Magento's default search algorithm is garbage. Incredibly, instead of using AND for an operator it uses OR, which means that the more terms you use to refine your search, the more results you get. It's completely backwards!

There is a truism when it comes to learning Drupal — once you've built your first site, throw it away and use what you've learned to build it again correctly. There were a few times along the way that I thought this about our Magento development process as there is certainly a learning curve and a 'right way' to architect it.

Now that we've launched, I've certainly got no regrets about choosing Magento as an ecommerce platform, and I'm looking forward to everything we can do to expand and enhance it.

The fastest growing eCommerce platform in the recent past, Magento is a PHP based Open Source eCommerce platform. Magento is also the youngest member of the eCommerce platform family; that said the brains behind the product have been around in the industry for quite a while – and that experience quite as well reflects in the product offering.

Magento offers a rather unique combination of a broad set for out-of-box ecommerce features and an intuitive user interface. This comprehensive feature set covers most aspects of an eCommerce solution including product and catalog management, order management, marketing and promotions, customer self-service, user management as well as customer support functions. These features not only allow merchants to deploy simple yet feature rich eCommerce storefront rather quickly, but also provide the backend admin interface with the toolset to allow you to manage your ecommerce operations effectively. This combination is not too common in the product segment that it is most popular in – the small and medium eCommerce platform segment.

Magento is well suited for direct to customer storefronts that offer a limited number of products to its customer like Boutique storefronts, single or Multi-Brand storefronts, Manufacturers and the likes. Magento however is not the best solutions for merchants who offer a large number of products (above several thousands) like large retailers or enterprises that need tight integration of eCommerce with their enterprise systems.

Magento offers three editions as well as a SaaS offering which serve as a cost effective alternative options for customers who are just starting on their eCommerce journey and are not willing to invest in large enterprise solutions.

Do remember that Magento has been dogged by performance issues and is also known for system complexities – the primary source of Magento’s limitations and shortcomings.

Vendor Summary

Magento traces back its root to Varien Inc. – a company originally founded by Roy Rubin in 2001 and later joined by Co-Founder Yoav Kutner. The company worked on osCommerce (an Open Source e-Commerce project) however the team wasn’t too satisfaction with osCommerce as a platform. In 2006 Varien planned a fork from osCommerce but then later dropped the idea and decided to build a completely new e-Commerce platform from scratch. This development work began in January 2007 on what is now known as Magento and the first beta version was release on 31st August, 2007. The product was well accepted and the first stable release on 31st March, 2008. In January 2009 itself Magento was names as an ‘Emerging Player to Watch’ by Forrester in ‘Forester Wave: B2C eCommerce Platforms, Q1 2009’.

Varien was officially renamed at Magento in 2010, around the time when eBay bought a 49% stake in Magneto in March 2010. The minority stake buy out wasn’t officially disclosed until a 100% acquisition by eBay in July 2011. While the official figures are unknown, unconfirmed reports claim that the acquisition was prices at $180M US. This acquisition seems to have been part of eBay’s X.Commerce strategy and Magento is expected to be an important component of it.

While this is defiantly good news for Magento – the eBay support and funding will give Magento an opportunity to fire all its cylinders and accelerate its growth; do keep in mind that eBay has also recently acquired other ecommerce product like GSI Commerce (for $2.4billion) and Intershop (majority stake only of 27%).

Product Summary

Magento is a PHP based Open Source eCommerce platform – licensed under Open Software License (OSL 3.0). Magento eCommerce offering is available in three editions – Magento Community, Magento Professional and Magento Enterprise edition. Of these Magento Community is the freely available open source editions; the other two are commercial open source editions – have an enhanced feature-set, maintenance, supports and come with a price tag. Magneto also offers a hosted SaaS service ‘Magento Go’ that helps customers gets started on their eCommerce journey rather easily.

Magento’s first stable version was released on 31st march 2008 and has been rapidly gaining popularity ever since. In April 2009, Magento launched its commercial open source offering ‘Magento Enterprise Edition’ – this version has a border feather set and complemented with a support services agreement. This was followed by the release of Magento Mobile platform in September 2010 – the platform allowed developers to easily create native storefront applications for mobile devices. These mobile apps tightly integrated with their Magento eCommerce platform.

Keep in mind that Magento is undergoing constant evolutions with new features getting added at a fast pace.

Technology

Architecture

Magento has been built on the LAMP (Linux, Apache, MySQL and PHP) however it also runs on Windows. Magento has been built using the popular Zend framework. One the most important unique selling point (USP) of Magento is its flexibility – Magento adopts OOPs standard, Model View Controller (MVC) architecture and Event-Driven Architecture (EDA) enabling loosely coupling of the various layers and components. Magento also implements Entity-Attribute-Value (EAV) data model instead of the traditional RDBMS data model. While these architectural decisions bring in significant flexibility into the system; on the down side they result in an equally complex system that’s a difficult to customize and extend. As a result the platform is also known to be sluggish and requires a heavy hardware footprint.

Architecturally Magento can be considered as a collection of modules – each module is an independent application implementing MVC. MVC implemented in Magento is not the traditions MVC implemented in Java or PHP – it implements configuration based MVC. This means that each module’s is governed by a config.xml – the module will only load the classes / configuration explicitly declared in the file. Unlike the conventional MVC is will not automatically load a class once added in the module codebase.

Magento model implements Object Relational Mapping (ORB) that allows you to manage your database directly from your PHP code – no longer need to write SQL queries. Nevertheless a Magento model also comprises your business logic – something that’s traditionally delegated to the Controller. Magento Models can be classified as traditional Table-Column-Record model and the EAV model that’ spans across multiple table.

Unlike tradition controllers, Action Controllers in Magento MVC do not pass data object to View. Instead, Views are broken up into Templates and Blocks (see Templates section). Blocks are PHP objects that handle data while templates handle the presentation of this data – it is a combination of HTML and presentation related PHP.

Similar to other LAMP/WAMP offering, installation is a pretty straight forward process. Do however ensure that system prerequisites have been met.

Security

Out of box, Magento used its native authentication and authorization system. It allows you to register customer for your storefront as well as user for Magneto’s administration interface. Magento user management allows you to define your own custom Roles – these roles can be granted access to granular level access to individual Magneto resource allowing you to create a strong authorization model for your stores.

Surprisingly though Magento does not support integration with external or enterprise authentication systems like OpenID, LDAP or Active Directory.